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ABSTRACT 


This  tfwsis  explores  the  Navy  Heattti  Care  Strat^c  Planniiig  Process  (NHCSPP)  and 
attempts  to  q>ph^  die  Department  of  Defense  Automated  Infcmnation  Systems  (AIS) 
Documentation  Standard  (DOD‘STD-793SA)  to  develop  a  draft  a  functional  deso^on 
for  die  automation  of  the  NHCSPP  as  modufe  oi  the  Navy  Medical  Executive  hifoimation 
System.  The  diesis  b^ins  widi  a  discussion  of  Wartime  and  PeacelinM  Healdi  Care 
Planniiig.  This  is  fdlowed  by  an  in  depdi  evaluation  of  die  Navy  Healdi  Care  Strat^c 
Planning  Process.  The  Navy  Medical  Executive  hiformadon  Syston  is  dim  discussed, 
fdlowed  by  the  Functional  Descr^on  Overview.  Tlw  research  indicates  diat  Navy  Heahh 
Care  Strat^c  Harming  is  an  extreme)^  ccmiplex  and  intricate  process  and  as  such, 
traditional  methodologies  dial  enqihasize  uqituriitg  and  representing  users'  requirements 
iqifrQnt,  i.e.  DOD-STD-7935A,  are  not  approfmate  for  automating  the  jdarming  process. 
Additionally,  die  health  care  (danning  process  needs  to  be  standardizied  across  all  branches 
of  die  armed  services.  R  is  ftnlfaer  recommended  that  Navy  Medidne  oeate  a  wmigroiq) 
of  end-users  and  functional  experts  to  devdop  a  more  detail  fimctioiud  descr^on. 
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L  INTRODUCTION 


A.  BACKGROUND 

heat^  care  costs  and  atuinking  defense  bu^ietB  pronqited  die  Dqiartmail  of 
Defense  (DOD)  to  reevaluate  its  metfiod  of  ddiveiy  of  health  care  to  its  bmefidaiy  popu¬ 
lation.  As  a  result,  in  October  1991,  then  Dqwty  Secretary  of  Defoise,  D.J.  Atwood  initi¬ 
ated  the  development  of  the  Defense  Health  Program  (DHP).  [Ref  1]  Under  the  DHP, 
the  services  were  tadied  to  provide  hig^-quality  healdi  care  maximizing  cost- 
efiectivcness.  [Ref.  1]  In  answer  to  tfus  tasking,  the  Navy  Medical  Department  developed 
die  Navy  Health  Care  Strategic  Planrung  Process  (NHCSPP). 

B.  OBJECTIVES 

The  objective  of  this  diesis  is  to  ejqilore  the  NHCSPP  and  to  attenqit  to  dervelop  a  draft 
fimctional  descrqition  for  die  NHCSPP  module  of  the  Navy  Mediud  Executive  Informa¬ 
tion  System  (EIS).  The  functional  draft  descr^tion  developed  in  this  them  should  be  used 
as  a  basis  for  automating  die  NHCSPP. 

C.  THE  RESEARCH  QUESTION 

Two  main  research  questions  addressed  diis  thesrs  are:  how  is  militaiy  l^aldi  care 
planning  done  and  what  means  is  it  possible  to  ctqiture  and  rqires^  die  ]dtmning  proc¬ 
ess  requirements?  These  questions  are  investigated  using  existing  documentatkm  c<mi- 
bined  with  interviews  of  key  perstxmel  currently  involved  with  the  NHCSPP,  ie..  Navy 
Medical  Department  Executive  Manago',  Bureau  of  Mediciiw  and  Sur^y  staff  anafysts 
and  Medical  Treatment  Facility  planners. 
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D.  SCOPE,  LIMITATIONS  AND  ASSUMPTIONS 


1.  Scope 

This  tfiesis  investigates  ^  Navy  HeaMi  Care  Plannipg  ProcMses  conducted  during 
war  and  in  peace  time.  A  draft  ftmctiooal  deaeration  L  also  presented.. 

2.  Limitation 

The  draft  ftmctional  description  developed  in  this  thesis  is  to  be  presented  to  the 
Naval  Medical  bifocmation  Mani^ement  Center  (NMIMC),  ^ch  has  tesponsil^ty  for 
the  design  and  development  of  the  conqtlete  Navy  Medical  EIS.  Time  and  resource  con¬ 
straints  did  not  aOow  for  the  development  of  a  complete  functional  description. 

3.  Assumptions 

The  standard  IX)D  Functional  Desorption  format  '^cquirements  (Department  of 
Defense  Automated  Information  Systems  (AIS)  Documentation  Standard 
DOD-STD-7935A)  are  used  to  prepare  a  draft  functional  desorption  of  Navy  Medical  Ex¬ 
ecutive  Information  System  NHCSPP  module.  This  draft  functiorud  desorption  will  be  re¬ 
viewed  by  the  Navy  Medical  Information  Maruigement  Center  Executive  hiformation 
System  Project  staff  for  acceptance. 

E.  LITERATURE  REVIEW 

The  following  documents  provided  die  initial  research  for  the  formulation  of  this  dieds: 

•  h&sion  dement  Needs  Statement,  Navy  Medical  Department  Decision  Support  Sys¬ 
tem,  Naval  Medical  Information  Management  Center,  MAY  7, 1988 

•  Navy  Medical  Executive  Information  System  Migration  Plan,  Decision  S^tems  Tech¬ 
nologies,  INC.,  OCT.  1992 

•  Department  of  Defense  Automated  hiformation  Systems  (AIS)  Documentation  Stan¬ 
dard  DOD-STD-7935A,  OCT.  1988 
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•  Total  Quality  and  Productivity  Management  in  Health  Care  Oigamzatkms,  VinceiU  K. 
Omachanu,  Ph.D.,  P.£.,  Institute  of  Engineere  and  the  American  Society  for  Quality 
Control,  1991 

*  Introduction  to  Matured  Care ,  Health  Maintenance  Organizations,  Preferred  Pro¬ 
vider  Organizations,  and  Competitive  Medical  Plans,  Robert  G.  Shouldice,  hifoima- 
tion  Resources  Press,  1991 

F.  METHODOLOGY 

The  drait  functional  description  prepared  for  this  thesis  follows  the  Department  of  De¬ 
fense  Automated  Information  Systems  (AIS)  Documentation  Standard  DOD-STD-7935A, 
October  1988. 

G.  ORGANIZATION  OF  THE  STUDY 

This  diesis  begins  with  a  discussion  of  war  and  peace  time  health  care  planning  proc¬ 
esses,  followed  by  an  in  dq>th  evaluation  of  die  NHCSPP.  The  Navy  Medical  US  back¬ 
ground  and  general  design  theory  are  discussed,  followed  by  the  draft  functional 
description. 

This  thesis  is  organized  as  follows:  Cluster  n  discusses  the  Wartime  Health  Care  Plan¬ 
ning,  Chapter  m  discusses  Peacetime  Health  Care  Planning  and  Chapter  IV  provides  an 
analysis  of  die  Navy  Health  Care  Strategic  Planning  Process.  Chap  cr  V  provides  an  over¬ 
view  of  die  Navy  Medical  EIS  then  Chapter  VI  presents  the  DOD  standards  for  developing 
a  Functional  Description  and  rqrphes  these  standards  to  develop  a  draft  functional  descrip¬ 
tion  of  die  NHCSPP  module  of  the  Navy  Medical  EIS.  Chapter  VII  provides  conclusions 
and  recommendations  for  improvements  to  the  Navy  Medical  EIS,  NHCSPP  and  DOD 
documentation  standards. 
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II.  WARTIME  HEALTH  CARE  PLANNING 


Responsibility  for  waitiine  health  care  planning  begins  in  tfie  joint  service  environment 
widi  tfie  Jdnt  Chiefs  of  Staff  (JCS).  This  re^>onsibility  is  tfien  passed  to  die  Unified  Com¬ 
manders  and  dten  on  to  the  Conqxment  Commanders.  Wartime  health  care  planning  is 
done  separately  from  peacetime  health  care  planning  and  includes  separate  modds  and  in¬ 
formation  system  siqiport.  These  models  and  infonnation  are  used  during  wartime  as  well 
as  during  training  exercises.  [Ref.  2]  The  doctrine  for  joint  operation  is  laid  out  in  Joint 
Pub  4-02  [Ref  3]. 

A.  MISSION 

During  time  of  war,  die  mission  of  health  service  support  system  (HSS)  is  to  minimize 
the  effect  of  disease,  injuries  and  wounds  on  die  unit  readiness,  effectiveness  and  morale. 
This  mission  is  acconqilished  through  a  phased  health  care  system  (echelons  of  care)  that 
extends  fixrni  diose  measures  taken  at  the  point  of  wounding,  injury  or  illness  to  evacuation 
fi-om  a  theater  of  operation  for  treatment  at  a  continental  United  States  (CONUS)  hospital. 
The  effectiveness  of  the  system  is  measured  by  its  ability  to  return  patients  to  duty  quickly 
and  as  far  forward  in  die  dieater  of  operatiems  as  possible  wtiile  minimizing  mor^adity  and 
mortality.  [Ref  3] 

R  ORJECTIVES 

The  objectives  of  wartime  health  care  planning  are  as  follows; 

1.  As  delineated  in  the  Joint  Pub  4-02  [Ref.  3]  the  fimdamental  objective  of  the 
HSS  is  to  conserve  the  combatant  commander's  fighdi^  strength  of  land,  sea, 
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and  air  forces.  In  joint  operations,  dus  objective  is  most  effectively  realized 
through  die  optimum  use  and  migration  of  aO  available  component  command 
HSS  resources. 

2.  Effective  HSS  enhances  the  combat  strength  of  die  j(mt  force  by  maintaining 
physically  fit,  emotionally  well  personnel  and  by  treating  die  sick,  injured,  or 
wounded  in  a  manner  diat  promotes  their  survival,  recovery,  and  expeditious 
return  to  duty.  Throi^  i^Hcation  of  the  principles  of  HSS  and  use  of  the 
echelons  of  care  discussed  below,  commanders  can  better  retain  acclimated  and 
eiqierienced  persotmel.  In  retaining  such  personnel,  the  requirements  for  re¬ 
placements,  patient  evacuation,  and  additional  logistics  8U{^)ort  ate  minimized. 

3.  In  their  inception,  the  echelons  of  care  and  princqdes  of  HSS  did  not  qieciiically 
address  joint  or  combined  operations;  however,  their  inqilementation  is  com¬ 
mon  among  Service  con^ionents  and  applies  to  HSS  planning  and  execution  by 
joint  force  commanders.  HSS  in  joint  operations  requires  condnuos  planning, 
coordination,  and  training  to  ensiue  a  prompt,  effective,  and  unified  health  care 
effort 

C.  ECHELONS  OF  CARE 

The  HSS  system  is  organized  into  five  echelons  of  care  that  extend  fitnn  die  point  of 
wounding,  injury,  or  tOness  throu^  die  dieater  of  operation  to  CONUS.  (See  Figure  2-1) 
Each  succeeding  echelon  of  care  possesses  die  same  treatment  capabilities  as  diose  eche¬ 
lons  forward  of  it  and  adds  a  new  increment  of  treatment  crqiability  diat  distinguishes  h 
fiom  die  previous  echelon. 
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Figure  2-1.  Echelons  of  Care 

1.  Echelon  I 

Care  is  rendered  at  the  unit  and  includes  self  or  buddy  aid,  examination,  and  emer- 
^ncy  Hfesatving  measures  such  as  maintenance  of  aimray,  contnrf  of  bleeding,  prevention 
and  control  of  shock,  and  preventi<»i  of  fiirdier  injuiy.  This  edielon  of  care  may  also  in¬ 
clude  an  aid  station  ttiat  has  a  i^iysician.  Treatmoit  at  die  aid  station  may  involve  restora¬ 
tion  of  airway  by  suigical  procedure,  use  of  intravenous  fluids,  antibiotics,  and  triplication 
of  splints  and  bandages.  These  conrirehensive  elements  of  medical  managnnent  prepare 
patients  for  return  to  duty  or  for  transportation  to  a  hi^er  echekm  of  care. 
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2.  Echelon  II 


Care  is  rendered  at  an  HSS  oi]ganizati<m  by  a  team  of  i^tyadans  and  in  some  cases 
nurses,  siqiported  by  a  medical  technician  staff.  This  echelon  of  care  includes  basic  resus¬ 
citation  and  stabilization  and  may  also  include  surgical  u^Mbility,  basic  laboratory,  phar¬ 
macy,  and  tenqxnary  holding  ward  facifilies.  At  this  echelcm,  examinatimis  and 
observations  can  be  accon:q>lished  in  a  more  defiberate  maimer  dian  at  Echelon  I.  Tbe  ob¬ 
jective  of  tfiis  phase  of  treatment  is  the  application  of  emergency  procedures,  such  as  resus¬ 
citation,  prevention  of  imminent  death,  or  loss  of  limb  or  body  function.  For  those  patients 
who  require  a  more  comprehensive  scope  of  treatment,  arrangements  are  made  for  surface 
or  air  evacuatirm  to  a  facility  that  can  provide  die  required  treatment. 

3.  Echelon  III 

Care  rendered  requires  clinical  capabilities  normally  found  in  a  medical  treatment 
facility  (MTF)  diat  is  staffed,  equqiped,  and  located  in  an  environment  with  a  low  level  of 
ttireat  of  enemy  action.  Care  at  ttiis  echelon  may  be  die  initial  step  toward  restoration  of 
functional  health,  as  distinguished  from  procedures  diat  stabilize  a  condition  or  prolong  life. 
Unhanqiered  by  die  crises  aspects  of  initial  resuscitadve  care,  this  echelon  of  care  m^  pro¬ 
ceed  with  a  greater  d^tve  of  deliberation  and  preparation. 

4.  Echelon  IV 

Care  is  normally  provided  in  an  MTF  staffed  and  equqiped  for  d^nitive  care  and 
normally  includes  surgical  crqiabitity. 
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5.  Echelon  V 


Care  rendered  is  convalescent,  resUvative,  and  rehabilitative  and  is  normally  pro¬ 
vided  by  militaiy.  Veterans  Administration,  and/or  civilian  hospitals  in  CONUS.  This 
phase  may  encompass  a  period  of  minimal  care  and  increasing  phyacal  activity  necessary 
to  restore  patients  to  functional  health  and  allow  tfieir  return  to  duty  or  useful  life. 

D.  PATIENT  EVACUATION 

Evacuation  of  patients  in  die  combat  zone  or  from  Echelon  I  to  Echelon  n,  from  Eche¬ 
lon  n  to  Echelon  m  and  within  Edielon  IQ  is  normally  the  responsibility  of  component 
commands.  Evacuation  of  patients  from  the  combat  zone  to  die  communications  zone  or 
between  Echelon  in  and  IV,  from  the  communication  zone  to  CONUS  or  between  Eche¬ 
lon  IV  and  V,  and  within  CONUS  is  lUMmally  provided  by  die  component  commands  of 
die  US  Transportation  Command. 

E.  PRINCIPLES  OF  HEALTH  SERVICES  SUPPORT 

Eadi  Service  component  has  an  HSS  system  that  generally  involves  six  health  care 
principles: 

1.  Conformity 

Conformity  with  the  commander's  strategic  or  tactical  plan  is  the  most  basic  ele- 
.  .tent  of  effective  HSS.  The  HSS  plarmer  can  he^)  ensure  conformity  by  taking  part  in  the 
develoinnent  of  the  conunandets  plan  of  operation. 

2.  Proximity 

The  objective  of  dus  piinc^le  is  to  provide  the  HSS  to  die  sick,  injured,  or 
wounded  as  close  to  die  area  of  combat  operations  as  the  tactical  situation  permits. 
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Patients  ate  evacuated  to  an  MTF,  or  dM  fiuality  is  moved  to  die  area  wfaoe  die  patient 
population  is  die  greatest 

3.  Flexibility 

The  otdective  of  dus  piinc^  is  to  be  prepared  to  shift  HSS  resources  to  meet 
dunging  requirements.  Changes  in  tactical  plans  or  operations  make  flexibility  in  HSS  es¬ 
sential.  Because  all  HSS  units  are  used  somewhere  within  the  dieater  of  operation  and 
none  are  held  in  reserve,  plans  for  redistriinition  of  HSS  resources  are  required. 

4.  Mobility 

The  objective  of  diis  principle  is  to  ensure  HSS  assets  ranain  close  enough  to  8iq>- 
port  combat  forces  during  operations.  Throi^  the  use  of  organic  and  non  organic  trans¬ 
portation  resources,  commanders  must  be  aide  to  nqridty  move  HSS  units  to  siqiport 
combat  operations. 

5.  Continuity 

The  objective  of  diis  principle  is  to  provide  optimum,  uruntemiided  care  and  treat¬ 
ment  to  die  sick,  injured,  and  wounded.  Continuity  in  care  and  treatment  is  achkved  by 
moving  die  patient  dirough  die  progressive,  phased  HSS  system,  which  extoids  from  the 
ftffward  area  of  die  combat  zone  to  an  area  that  is  as  far  rearward  as  die  padenfs  condition 
requires,  possibty  to  CO^iT.^S.  Continuity  is  also  achieved  by  providing  required  care  dur¬ 
ing  movement 

6.  Coordination 

The  otdective  of  dus  princqile  is  to  oisure  dut  scarce  HSS  resources  are  efBden:^ 
employed  and  siqiport  die  fdaimed  operation.  Continuous  coordination  ensures  dut  MTFs 
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arc  not  placed  in  areas  that  interfere  with  combat  operations.  Additional^,  continuous  co¬ 
ordination  guarantees  diat  die  scope  and  quality  of  medical  treatment  and  care  meet  profes¬ 
sional  standards  and  policies. 

F.  GENERAL  HSS  PLANNING  CONSIDERATIONS 

Effective  and  timety  fdanntng  and  coordination  are  essential  to  ensure  adequate  and 
sustainable  HSS  in  a  theater  of  qieradons.  Jcmt  HSS  planning  is  a  continuous  process;  die 
joint  forces  command  surgeon  must  remain  soisitive  to  the  demands  for  HSS  based  on 
constandy  changing  operational  requirement.  Proper  planning  permits  a  systematic  exami¬ 
nation  of  all  factors  in  a  projected  operaticm  and  ensures  interoperability  widi  the  dieater 
campaign  plan.  The  organization  of  die  HSS  syston  k  determined  to  a  great  extent  by  die 
mission  of  die  joint  force,  die  medical  threat,  medical  intelUgaice  about  die  dreato*  evacua- 
don  policy,  and  hospitalization  and  evacuation  requirements. 

1.  Medical  Threat 

The  medical  threat  is  die  composite  of  aH  ongoing  or  potential  enemy  actions  and 
environmental  conditions  diat  might  act  to  reduce  the  performance  effectiveness  of  die 
joint  force  through  wounds,  injuries,  diseases,  or  psychological  aspects  of  die  combat 
environment. 

2.  Medical  Intelligence 

Medical  intelligence  is  threat  intelligence  produced  from  the  collection,  evaluation, 
and  analysis  of  information  concerning  the  medical  aspects  of  foreign  areas  diat  have  im¬ 
mediate  or  potential  impact  on  polides,  plans  and  operations. 
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3.  Medical  Evacuation 


Timely  medical  evacuation  plays  an  impoftant  role  in  the  carefulty  designed  treat¬ 
ment  sequence  from  front  to  rear.  As  die  echdons  of  HSS  become  more  so{dusticated 
from  front  to  rear  areas,  so  do  die  means  of  patient  evacuation.  Patient  evacuation  in¬ 
volves  planning  routes,  controlling  movement,  and  locating  evacuation  facilities.  The 
evacuation  of  patients  in  a  theater  of  operations  will  be  b>’  aircraft  when  air  transportation 
is  available,  feasible,  and  die  padenfs  condition  permils.  However,  aO  available  forms  of 
transpoftatian  must  be  considered  tc^ether  widi  the  details  of  patient  handling.  Require¬ 
ments  may  exist  for  surface  medical  transportation  such  as  field  and  bus  ambulances, 
trains,  andsh^. 

4.  Exceptions 

As  an  excqition  to  die  practice  that  component  commanders  provide  for  medical 
evacuation  in  their  area  of  operation,  guidance  for  medical  evacuation  of  formerly  crqitured 
or  detained  US  forces,  civilians  acconqiaiiying  US  forces,  enemy  prisoners  of  war  (EPW), 
civilian  inters,  and  odier  detainees  may  be  issued  by  die  joint  forces  commander. 

G.  THE  HSS  ESTIMATE  OF  THE  SITUATION 

The  purpose  of  die  estimate  is  to  coDect  and  analyze  HSS  information  pertaining  to  en¬ 
emy  intentions  and  fiiendly  capabilities,  limitatiotts,  courses  of  action,  and  potential  conse¬ 
quences  associated  widi  a  contenplated  operation.  The  estimate  may  be  written  or  oral. 

The  HSS  esdmate  will  consist  of  HSS  facte,  assunqitions,  and  deductions  diat  can  af¬ 
fect  die  operation.  In  diis  Ir^cal  and  orderly  exammadon  of  all  the  HSS  fectors  affecting 
mission  accomplishment,  die  command  surgeon  must  be  familiar  with  die  joint  force 
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comnuaidei's  concept  of  operatknis  and  obtain  medical  mtdHgence  about  die  area  of  op¬ 
erations  from  indigmous  sources,  the  siqiporling  intelligence  activily,  the  Aimed  Forces 
Medical  Intelligence  Center,  and  national  intelligence  i^encies.  The  command  surgeon 
should  conduct  a  ttiorough  evaluation  of  die  enemy  situation,  friend^  situation,  and  the 
area  of  operations  from  die  stan<4>oint  of  the  effects  on  die  healdi  of  die  joint  forces  and 
HSS  operations. 

Analysis  of  die  HSS  estimate  is  the  l<^cal  comparison  of  die  medical  threat  and  die 
HSS  dqubOities  to  determine  vulnerabilities  and  estimated  lequrrements  of  the  joint  force. 
Patient  estimates  are  calculated  for  numbers,  distribiition  of  time  and  qiace,  areas  of  den¬ 
sity,  possible  mass  casualties,  and  evacuatioiL  The  joint  force  command  surgeon  consults 
experience  tables  to  assist  him/her  in  determining  requirements  for  the  operation.  Frcmi 
dus  data,  hoqntals  estimates  and  other  siqiport  icquiranentB  are  derived. 

Having  determined  die  HSS  requirements,  die  command  surgeon  considers  die  re¬ 
sources  that  are  readily  available  to  meet  die  requirements.  Maximum  use  of  die  available 
peisoimel,  siqiplies,  and  equqmient  and  joint  use  of  facilities  promotes  overrJl  effectiveness 
of  die  command's  HSS.  Taking  into  consideration  ad  siqiport  lequiTements  and  resources 
available,  die  command  surgeon  determines  which  proposed  course  of  action  can  be  sup¬ 
ported  from  die  HSS  perspective. 

H.  HSS  PLANNING  FACTORS 

In  addition  to  coordinating  joint  force  I£»S  requirements,  basic  planning  for  HSS  in 
joint  operations  can  involve  several  major  considerations;  coordinating  HSS  requirementB 
with  odier  combatant  commands  as  required  and  coordinating  widi  allied  and  odier  fiioidly 
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forces.  The  pnmaiy  tool  used  in  HSS  planning  is  die  Joint  Operation  Planning  and  Execu¬ 
tion  System  (JOPES)  Medical  Planning  Module  (MPM).  The  MPM  is  an  automated  q>- 
plication  program  diat  takes  the  joint  force  provided  casualty  figures  and  project  the 
inq>act  an  operation  wiO  have  on  the  HSS  system.  It  also  provides  estimates  of  require¬ 
ments  for  such  things  as  medical  evacuation  assets  and  number  of  beds. 

The  theater  patient  evacuaticn  policy  is  established  by  the  Secretary  of  Defraise,  with 
die  advice  of  the  Chairman,  Joint  Chiefs  of  Staff,  and  the  recommendation  of  die  joint 
force  commander.  The  policy  prescribes  die  maximum  number  of  MTF  bed  days  for  a 
patient  within  the  theater.  However,  a  patient  is  not  required  to  be  held  in  the  dieater  of 
operation  for  the  entire  period  stated  in  die  theater  evacuation  poKc^.  Any  patimt  ndio  is 
not  e^qiected  to  be  returned  to  duty  within  die  number  of  days  expressed  in  die  theater 
evacuation  policy  is  evacuated  as  soon  as  medical  officers  have  determined  diat  travel  will 
not  aggravate  die  patient's  conditioiL  Shorter  time  periods  within  die  dieato*  of  operations 
before  patient  evacuation  reduces  die  dieater  MTF  bed  requirements  and  increases  die 
number  of  beds  required  elsewhere.  In  addition,  shorter  time  periods  before  evacuation 
also  increases  evacuation  requirements.  The  time  period  stated  in  die  dieater  evacuation 
policy  determines  when  a  patient  is  admitted  to  die  first  MTF  (mobile  or  fixed).  The  total 
time  a  patient  spends  in  all  MTFs  in  die  theater  of  operation  for  a  single  episode  of  illness, 
injury  or  wounding  should  not  exceed  die  number  of  allowable  days  of  noneffectiveness 
outlined  in  die  dieater  evacuation  policy.  This  policy  is  flexiUe  and  changes  as  the  tactical 
situatimi  shifis  to  ensure  that  nonfixed  MTFs  retain  mobility  and  the  crqiability  to  accom¬ 
modate  anticqiated  surges  of  patients. 
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The  estimate  for  ttieater  MTF  bed  requirements  is  based  on  empirical  data  acr.iiynii|f|f<»^ 
fn-  each  Service  for  the  two  major  categories  wounded-in-action  (WlA)  and  disease,  non- 
battie  injury  (DNBI).  The  etiqnrical  data  are  adjusted  to  take  into  consideration  such  £«;- 
tors  as  the  dieater  evacuation  poficy  and  the  necessity  for  segregating  patients  by  gender  or 
nature  of  contagious  disease.  The  formula  for  calculating  theater  MTF  bed  requirements  is 
shown  in  Figure  2-2.  The  terms  and  formulas  are  di8cus<^ed  below. 


Admission  Popuktion  Accumulation  Dispersion  Beds 

Rate  (000)  Factor  Factor  Required 


WIA  XXX 


raJBI  X  X  _  X 


Total  Beds 

Figure  2-2.  Calculation  for  Theater  Bed  Requirements 
1.  Admission  Rate 

A  numerical  expression  of  die  relative  frequency  widi  which  patients  are  admitted 
to  MTFs  from  a  specified  population  over  a  designated  period  of  time.  The  Service  com¬ 
ponents  use  difTomit  methods  for  confuting  admission  rates.  The  command  surgeon  will 
use  the  admission  rates  provided  by  the  component  command  to  formulate  joint  force  re¬ 
quirements.  The  admission  rates  are  usually  e^q»essed  as  die  number  of  admisaons  to  an 
MTF  per  diousand  average  personnel  strengdi  per  day. 
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2.  Population 

The  number  of  personnel  in  the  operation  to  be  siq>pofted  by  the  HSS  syston. 

3.  Accumulation  Factors 

The  rate  patient  population  increases  in  MTFs  under  qwcified  evacuation  pohdes. 
Two  metfiods  are  ncmnaHy  used.  One  method  indicates  how  many  patimts  will  have  beoi 
accumulated  at  the  end  of  specified  periods  of  time  based  on  a  coi  stant  admission  of  one 
patient  per  day  and  a  constant  fixed  evacuation  policy.  The  odier  method  shows,  for  die 
number  of  patients  admitted  on  any  one  day,  die  proportion  that  will  remain  at  the  end  of 
each  specified  period. 

4.  Dispersion  Factors 

A  facta-  appKed  to  die  number  of  anddpated  patients  to  make  allowances  for  sev¬ 
eral  difScult  to  control  factors,  such  as  the  movement  of  MTFs  that  is  often  required  in 
combat,  s^r^adon  of  patients  based  on  gender,  separate  wards  for  cond^us  diseases, 
and  the  requirement  diat  conqilete  MTFs  must  be  furnished  for  all  units  diat  operate  smne 
distance  fixrni  die  main  body  of  forces. 
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This  s&owaiK^  provides  a  cushkm  of  additional  emi^  beds  against  surges  in  patioit  flows. 


Figure  2-3  is  an  exanqde  of  die  total  bed  requireinents  calculation. 


Adtniaaian  Popukbon  Accumulation  Dnpenion  Beda 

Rate  (000)  Factor  Factor  Required 

WIA _ 0.2_  X  500  X _ ^0.4 _  X  _0.2 _  = _ 8 _ 

DNBI _ 0.1 _ X  500  X  _ ^0.2 _ X _ 0.2 _ =  _2 _ 

Total  Beds  10 

Figure  2>3. 

The  numbers  used  in  figure  2-3  are  hypodietical  and  in  no  way  represent  real  wartime  con¬ 
ditions.  The  total  beds  is  per  diousand  persoimel  in  theater  per  day. 

This  approach  to  HSS  planning  is  used  in  all  wartime  situations  fiom  high  intensity 
conflict  to  low  intensity  conflict.  This  enconqiasses  HSS  for  special  operations,  in  riveiine 
environment,  and  combat  search  and  rescue  operations.  This  process  of  HSS  (banning  is 
only  used  in  a  wartime  environment  or  during  training  ibr  a  wartime  environment  and  is 
not  ^licable  to  peacetime  health  care  planning.  ThereftMe,  diis  process  will  not  be  fac¬ 
tored  in  as  a  requirement  in  die  functional  descr^on  of  die  Navy  Healdi  dlare  Strat^c 
Planning  Process  Module  of  the  Navy  Medical  Executive  Information  System.  The  next 
chrqiter  discusses  heath  care  planning  during  peacetime. 
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III.  PEACETIME  HEALTH  CARE  PLANNING 
This  chapter  discusses  peacetime  health  care  {danning  and  die  devdopment  of  dte 
NHCSPP.  Also  included  in  this  chapter  is  an  introduction  to  the  NHCSPP  and  a  discus¬ 
sion  of  the  Coordinated  Care  Program. 

A  PEACETIME  HEAI,TH  CARE  PLANNING  BACKGROUND 

The  following  mfoimadon  was  gathered  during  a  interview  with  Commander  (CDR) 
Diane  Ledonne,  Nurse  Corps,  United  States  Navy,  from  tfic  ofiBce  of  Ac  Assistant  Chict 
for  Plans,  Analysis  and  Evaluation,  Bureau  of  Medicine  and  Surgery  (BUMED).  [Ref.  S] 
CDR  Ledoime  is  considered  to  be  a  subject  matter  e^qrert  in  Ae  area  of  peacetime  hcahh 
care  planning.  She  has  been  invdved  wiA  Navy  HeaUh  Care  Planning  since  its  inception 
in  1981. 

1.  The  Beginnings 

It  was  not  until  early  in  Ae  1980s,  that  healA  care  planning  within  Navy  Medicine 
actually  began.  The  driving  forces  for  healA  care  planning  were  technical  and  monetary 
developments  within  Ae  civilian  heahh  care  sector,  cost  efTectiveness  questions  from  Ae 
fr^t  line  commanders,  and  a  rapid  growA  in  medical  biDets  required  by  Ae  greater  em¬ 
phasis  placed  on  Navy  Medicine.  As  such,  Ae  focus  during  Ais  period  was  cost-based. 
Also  Acre  was  added  focus  on  Medical  Treatment  Facility  (MTF)  stafBng  requirements. 
Some  of  Ae  major  milestones  developed  during  this  time  were  Ae  development  of  Ae  first 
"Heahh  Care  Dehvety  Plan"  at  Naval  Hospital  lAibde^ihia,  Perms^varda  and  Ae  creation 
of  a  new  BUMED  code,  designated  Regiotud  Operations  Divmon.  Navy  Medicine,  in  an 


effoil  to  keep  pace  with  &e  afore  mentioned  changes,  began  to  design  innovative  heath 
care  delivery  options  which  included:  health  care  finders,  ambulatory  surgery,  and  outside 
contracting  for  health  care  services.  These  developments  required  a  renewed  eii:q>hasis  on 
quality  credendalling  of  healdi  care  providers  and  professionals.  [Ref  S] 

2.  The  Endorsement 

From  the  end  of  die  1980s  and  into  the  1990s,  Navy  Health  Care  Planning  re¬ 
ceived  even  further  endorsement  fixnn  die  Navy  Surgeon  General  and  the  line  command¬ 
ers.  The  driving  forces  behind  this  new  direction  became:  cost-cffccdvencss  and  efficiency 
erqrectation  from  the  Navy/Matine  Coix>s  line  communities,  the  active  involvement  of  die 
Navy/Maiine  Coips  line  communities  in  Navy  medical  administration,  further  growth  in 
Navy  Medical  billets  and  mission,  and  a  lack  of  confidence  in  civilian  health  care  providers. 
The  Navy  Medicine  plarmers  focused  on  cost,  efficiency,  staffing  requirements,  billet  allo¬ 
cation,  and  quality  of  care.  Some  of  die  major  milestones  included: 

•  Secretary  of  the  Navy  Webb,  established  six  (6)  goals  for  Navy  Medicine,  one  of 
which  was  Health  Services  Planning 

•  die  formulation  of  proposals  to  do  strate^c  health  care  planning 

•  the  completion  of  die  "Strategic  Plan"  for  Navy  Medicine 

•  the  Blue  Ribbon  Panel  Report  requires  Navy  Medicine  to  do  peacetime  heatdi  care 
planning 

•  a  BUMED  code  created  to  do  peacetime  health  care  planning 

•  die  development  of  die  "managed  care"  concept 

•  die  development  of  models  for  plaruung  and  utilization 
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•  the  stait  of  p(^ulati(m  ana^rsis  for  health  services  requireniaits 

•  the  Navy  Medical  Department  begins  the  devdopimnt  of  a  "business  idan" 

Peacetime  health  care  planning  is  becoming  increasing  important  as  budgets  are  cut  and  the 
Navy  right-sizes.  [Ref.  5] 

3.  Design  and  Development 

By  1992,  Navy  Medicine  was  deeply  involved  in  the  design  and  development  of  a 
peacetinie  health  care  planning  process.  This  process  was  designated  the  Navy  Health 
Care  Strategic  Planning  Process  (NHCSPP).  The  driving  forces  had  become;  die  Blue 
Ribbon  Panel  requirement  for  an  organized  program  for  health  care  {banning  and  evahia- 
don,  Govemmoit  Accounting  QfBce  and  Inspector  Goieral  inquires  into  Navy  Medicine 
fdamdng  methodologies,  and  the  Office  of  Assistant  Secretary  of  Defease,  Health  Affairs 
Coordinated  Care  Program.  The  focus  is  now  populadon/need  based  planning,  sophisd- 
cated  planning  methodologies,  the  use  of  informadon  systems  to  siqiport  planning,  and  die 
use  of  models  to  aid  die  field  and  headquarters  level  planners.  The  major  milestones 
include; 

•  active  Coordinated  Care  Program  in  die  Tidewater  Virginia  area 

•  Health  Care  Planning  Woricgroup  creates  die  Navy  Health  Care  Strategic  Planning 
Process 

•  Navy  Medicine  issues  its  "Strategic  Plan” 

•  development  of  eiqieitB  in  field-level  peacetime  planners 
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•  identification  and  dedgn  of  infoniution  systems  to  8iq>pott  peacetmw  heal^ 
planning 

•  design  and  test  of  the  tools  and  methods  for  peacetime  healtii  care  pUmimg 

In  the  face  of  base  closures,  force  right-sizing  and  budget  cuts.  Navy  Medicine  is  moving 
closer  and  closer  to  having  the  tools  necessary  to  meet  the  needs  of  if  s  customos  whetiier 
tfiey  be  patients  or  Congress.  [Ref.  S] 

4.  Empovrerment  and  Implementation 

£>uring  1993,  the  intensity  of  base  closures,  force  ri^t-sizing  and  bw^  cuts  es¬ 
calated.  For  Navy  Medicine,  die  inqioftance  of  peacetime  health  care  planning  has  come 
to  the  fore  front.  Navy  Medicine  is  empowered  to  begin  to  inqdement  peacetime  healdi 
care  planning.  The  driving  forces  are  now:  reduced  resources,  conqietition  widi  the  Navy 
Line  community  for  resources  (dodais  and  billetsX  health  care  reform  initiatives,  reorgani¬ 
zation  in  die  civilian  sector  and  a  rduft  from  specialization  and  hqiatient  services  to  primary 
care  and  ambulatory  services.  The  emphasis  now  is  on  rational  logical  use  of  standard 
models  and  information  tystems  in  an  int^ated  effort  by  field  and  headquarters  planning 
stafife.  The  mflestones  are: 

•  die  creation  of  BUMED  code  08,  Assistant  Chief  of  Plans,  Analysis  &  Evaluation 

•  decision  relating  to  ruval  hospital  closures  and  migrations  of  Navy  and  Marine  Corps 
personnei 

•  establishment  of  die  BUMED  Base  Realignment  and  Qosure  Commission  (BRAC) 
Action  Organization 

•  the  first  ever  peacetime  health  care  planning  worlcshop 
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*  conqdelkm  by  the  BRAC-affected  MTFs  of  a  Heattti  Care  C^Mbilitks  AsscMmait 

*  the  design  of  the  Kfihan  Modd  [Ref.  S] 

Since  the  banning  of  1993,  die  two  (2)  most  inqioftanl  milestones,  addiessed  by  ttns 
diesis,  sre  die  Coordinsted  Care  Program  (CCP)  snd  die  development  of  die  Navy  Healdi 
Care  Strat^c  Planing  Process.  The  CCP  program  is  inqiortant  because  the  NHCSPP  is 
die  foundation  for  CCP;  dierefore,  die  CCP  bears  discussing.  These  two  milestone  are  dis¬ 
cussed  in  more  detail  below. 

B,  COORDINATED  CARE  PROGRAM 

In  an  October  1,1991  memo.  Deputy  Secretary  Of  Defense  D.  J.  Atwood  [Ref  3]  dis¬ 
cussed  the  requirements  for  the  strengdiening  of  medical  functions  within  the  Department 
of  Defense  (DOD).  Mr.  Atwood  cited  die  t^tening  constraint  on  national  defense  budget 
as  justification  for  the  pursuit  of  die  aggressive  actions  necessary  to  execute  the  IX)D's  vital 
medical  missions  more  effectively.  He  directed  die  inqilementation  of  the  CCP.  Mr.  At¬ 
wood  indicated  diat  die  CCP  would  be  critical  in  die  strengiheriing  of  DOD's  ability  to  per¬ 
form  its  medical  mission  with  centralized  audiority  and  responsibility  but  decentralized 
imidementation  by  die  Mlitaiy  Departments.  He  directed  die  Assistant  Seoetary  of  De¬ 
fense  for  Health  Affairs  to  inqilement  a  program  to  ensure  coordinafion  within  afyropriate 
geographical  areas  of  the  provision  of  medical  care  in  DOD  facilities  widi  die  provision  of 
medical  care  through  die  Civilian  Health  and  Medical  Program  of  the  Uniform  Services 
(CHAMPUS).  The  stated  otgective  of  die  program  is  to  maximiTe  cost-^ectiveness  in  the 
delivery  of  high-quality  heiddi  care  in  keeping  widi  die  Departmoif  s  medical  mission.  In 
this  same  memo,  \fr.  Atwood  rqipointed  the  Assistant  Secretary  of  die  Defense  for  Healdi 
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AfGurs  (ASD(HS))  a$  ttie  DOD  ofiScer  re^ponsibie  for  the  effective  executiofi  of  EtOiys 
medical  mission.  Mr.  Atwood  declared  [Ref.  1]  tfie  medical  mimrimi  of  the  DOD  to  be: 

*  to  provide  and  maintain  a  readiness  to  provide  medical  and  siqipoft  services  totlie 
armed  forces  during  militaiy  operations  and 

*  to  provide  medical  and  siqyport  services  to  members  of  the  armed  forces,  dietr  depend¬ 

ents,  and  others  entided  to  DOD  medical  care. 

The  CCP  is  a  DOD  initiative  designed  to  provide  MTF  commanders  the  tools,  audior- 
ity  and  flexibility  necessary  to  better  meet  die  medical  mission.  [Ref.  4]  CCP  should  en¬ 
able  the  DOD  and  the  Medical  Departments  to  better  accomplish  the  medical  miBsion  by 
improving  beneficiary  access  to  and  control  costs  of  health  care,  vdule  at  the  same  time  en¬ 
suring  quality  care  to  all  Military  Healdi  Services  System  (MHSS)  beneficiaries.  [Ref  4] 
Central  to  die  CCP  win  be  die  local  healdt  care  deUveiy  systems  or  "networks"  based  on 
arrangements  between  military  and  civilian  health  care  providers  and  organizatioiis.  These 
networks  are  to  be  locally  maruiged  by  the  MTF  commanders  who  are  responsible  for  re¬ 
source  management  and  die  delivery,  c<wt,  and  quality'  of  healdi  care  services  provided  to 
baiefidaries  in  dieir  service  areas.  CHAMPUS  eUgiUe  beneficiaries  are  offered  diree  op¬ 
tions  for  receiving  health  care: 

*  CC-PLUS  in  which  beneficiaries  enroDed  receive  aO  healdi  care  fi-om  fsdlities  of  die 
unifoimed  service^'  and  civilian  network  providers 

*  CC-EXTRA  in  which  beneficiaries  use  the  civilian  preferred  provider  network  on  a 
case-by-case  basis  or 

*  CC-BASIC  in  which  beneficiaries  remain  in  die  standard  CHAMPUS  benefit  plan. 
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The  guiding  prim^des  for  die  design  and  imideniaitation  of  the  CCP  are; 

•  sorve  benefk^es  to  pravkte  a  coinbat<feady  force 

•  be  based  on  decoitralized  execution 

•  have  local  accountability  with  centralized  direction  and  momtofing 

•  achieve  greater  equity 

•  be  flexiUe  and  easy  to  administer  and 

•  optimize  use  of  MHSS  resource 

The  CCP  encourages  decentralized  executicm  and  accountability  CGiq)led  with  centralized 
direction  and  monitoring  by  the  Sovices  and  die  ASD(HA).  The  following  system-wide 
inqirovements  will  be  inqilemented  to  siqiport  and  cmnidement  local  health  care  ddiveiy 
netwoilcs: 

•  reforms  of  CHAMPUS  provider  payment  methods 

•  establishment  of  Specialized  Treatment  Facilities  (STF)  to  {vovide  hi^-technology 
/hig^-cost  health  care  services  in  die  most  cost-efifecdve  manner 

•  new  qiproaches  to  contracting  for  heatlfa  care  services 

•  die  establishment  of  pardcqiation  agreement  widi  civilian  providers  to  accept  CHAM¬ 
PUS  and  Medicare  assignment 

•  inqnovement  in  die  efiSciency  and  accuracy  of  claims  processing  and 

•  evoitualfy,  a  centralized  daims  processing  system  [Ref  4] 

The  inqilementation  of  the  CCP  is  to  be  acconqilidied  over  a  duee  (3)  year  period.  This 
phased  approach  is  due  to  die  scope,  size  and  complexily  of  the  MHSS,  the  extensive  CCP 
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reforms  and  the  need  to  tniniinize  any  detiimailal  effects  <ni  readiiiess  or  on  botefidaiies 
[Ref.  4]. 

C.  NAVY  HEALTH  CARE  STRATEGIC  PLANNING  PROCESS 

In  the  past.  Navy  Medicine  healdi  care  {darming  was  accomidished  wing  nqppty  diivai 
lustoiicai  workload  data.  The  healdi  care  planning  process  was  more  an  exerdse  in  a!kx»- 
tion  dian  in  actual  planning.  The'  Navy  Surgeor  General  recognized  a  need  and  an  oppor¬ 
tunity  for  changing  die  way  Navy  Medicine  cmiducted  health  care  [banning.  On  IS  Jufy, 
1992  die  Navy  Surgeon  GeiMral  diartered  die  Planning  Task  F(»ce.  The  Planning  Task 
Force's  mission  was  to  develop  a  peacetinw  healdi  care  requirements  {danning  mediodol- 
ogy.  The  group  consisted  of  muhidisc^linary  members  from  BUMED,  MTFs,  Center  for 
Naval  Analysis,  and  Corporate  Infrmnation  ManagonoiL  The  development  of  a  health 
care  planning  process  was  a  full-time  job  for  the  core  group,  while  functional  esperts 
where  called  in  to  augment  die  core  groip.  This  Planning  Task  Force  devekped  die  Navy 
Health  Care  Strat^c  Planning  Process  (NHCSPP).  This  process  is  discussed  in  a  detail  in 
die  following  clupter. 
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IV.  ANALYSIS  OF  THE  NAVY  HEALTH  CARE  STRATEGIC  PLANNING 


PROCESS  (NHCSPP) 

The  new  Navy  Health  Care  Strategic  Planning  Process  (NHCSPP)  represents  a  major 
shill  in  die  health  care  [danning  process,  by  changing  the  basis  for  planning  L  <  m  sqpply  to 
demand.  The  NHCSPP  is  in  line  widi  the  principles  of  Total  Quality  Leaders!)^  by  allow¬ 
ing  for  catchment  area  iiq)ut  and  variation.  A  catchment  area  is  a  forty  (40)  mile  radius 
aroimd  the  MTF.  The  NHCSPP  provides  a  framework  for  evaluating  changes  in  man¬ 
power,  money  and  material  in  the  direct  support  of  the  Program  Ob^tive 
Memorandum/Program  Planning  and  Budgeting  System  (POM/PPBS).  The  NHCSPP  al¬ 
lows  die  health  care  planner  to  evaluate  die  total  health  care  requtrements  for  MHSS  bene¬ 
ficiaries  in  the  local  catchment  area. 

The  NHCSPP  is  a  generic,  issue  driven  process.  Issues  being  defined  as  problem  areas 
identified  within  die  MTF  and  its  local  civilian  provider  networks.  The  NHCSPP  focuses 
on  die  customer  and  is  die  foundation  of  the  Coordinated  Care  Program  (CCP)  (see  chap¬ 
ter  2  for  an  e^lanadon  of  CCP).  The  NHCSPP  is  evolutionary  in  nature  a..d  modular  in 
design.  This  process  is  iterative  and  may  be  entered  at  arty  point  during  die  process  and 
also  allows  for  die  repeat  of  any  step  as  desired.  Figure  4-1  is  a  graphical  rqnesentation  of 
the  NHCSPP.  This  process  can  be  used  from  die  top  down  by  die  tystem-wide  plarmers  at 
BUMED  or  the  Healdi  Service  Organizations  (HSO)  as  well  as  fixrni  the  bottmn-iq)  by  die 
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MTF  health  care  pJamiers.  The  foDowii^  sections  discuss  each  step  of  the  NHCSPP  in 
somedetafl. 


Figure  4-1 

Navy  HeaKh  Care  Strategic  Planning  Process 


A.  roENTIFY  THE  ISSUES/PROBLEM 

This  is  the  first  step  in  die  process.  When  identifying  the  issues  affecting  his/her  facil¬ 
ity,  die  healdi  care  planner  must  consider  the  mission,  benefit,  goals  and  objectives,  existing 
guidance,  environment  and  opportunity.  Issues  being  problem  areas  identified  widnn  die 
MTF  and  its  local  civilian  provider  netwoiics.  These  issues  can  be  isolated  by  the  use  of 
customer  questimmatres  or  by  staff  and  support  personnel  of  the  MTF.  An  issue  could  be 
die  need  for  an  Ears,  Nose  and  Throat  clinic  or  die  starting  of  a  OB/GYN  {nacdce  in  house 
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or  a  need  to  see  die  entire  catchnwnt  area  population  for  this  MTF.  The  addition  of  a  q>e- 
cialty  doctor  ccnild  offer  the  possibility  of  (^>enn%  a  spedalty  dink  in  die  MTF  and  possi- 
bfy  reducing  the  cost  of  the  service. 

To  begin  die  process,  the  heatdi  care  planner  must  consider  the  MTFs  mission,  the 
health  care  benefit,  goals  and  objectives  of  the  issue  and  exkting  policy  guidance.  The 
health  care  planner  must  look  at  die  MTF  and  its  catchment  area  fiom  die  "customer  side", 
review  die  historical  data  bodi  fixrni  the  MTF  and  CHAMPUS,  and  scan  the  environment 
for  events  diat  influence  die  beneficiaty  populations.  The  iterative  nature  of  die  process  al¬ 
lows  die  planner  to  enter  the  process  at  die  demand  point  and  review  the  historical  demand 
for  services  and  die  related  costs  fiom  both  die  MTF  and  CHAMPUS,  and,  dierefore,  lo¬ 
cate  the  opportunities  for  improving  the  allocation  of  resources.  For  exanqile,  a  heatdi  care 
planner  reviews  die  historical  Level  II  CHAMPUS  data  and  finds  the  oncology  cost  to  be 
high-  Then  die  planner  would  review  the  hospital  stafBng  and  locate  date  (3)  onctdogy 
doctors.  At  diis  point,  the  issue  becomes  die  possible  opening  of  oncology  dink  within  the 
facility 

B.  SPECIFY' THE  POPULATION. 

After  a  clear  undeistanding  of  the  issue  facing  die  healdi  care  planner,  die  population 
of  interest  must  be  identified.  Geographical  boundaries  have  been  established  for  each 
MTF.  The  area  widun  the  established  boundaiy  around  the  MTF  is  called  die  catchment 
area.  Normally,  this  catchment  area  is  a  forty  (40)  mile  radius  around  die  MTF.  In  some 
cases,  diere  are  geogn^hical  obstades  that  would  need  to  be  considered.  This  includes  a 
major  water  way,  ocean  bay,  toll  bridge  or  a  mountain  ran^  as  diey  inqiact  die 
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benefidaiys  ability  to  gain  access  to  die  medical  facilities.  As  coordinated  care  concepts 
are  ai^lied  to  the  MIKS,  a  regionalized  approach  is  to  be  taken  when  defining  die  catch¬ 
ment  areas.  Where  multi-service  MTFs  have  oveihqiping  catchment  areas  now  under  the 
40  mile  radius  rule,  health  care  delivery  is  now  managed  fiom  a  tri-service  standpmnt 
[Ref.  6].  This  qiproach  affects  the  populadrm  of  interest  as  well  as  chaiigM  in  die  econ¬ 
omy,  homeport  changes,  training  schedules  and  the  ariiva]  and  departure  of  die  fleet.  A 
demographic  profile  of  a  catchment  area  must  consider  factors  such  as  race,  i^c,  gender 
and  zipcode.  The  result  of  dus  step  win  be  a  solid  demographic  profile  of  the  entire 
beneficiary  base. 

C.  ASSESS  THE  NEED. 

To  discuss  the  assessment  of  need,  a  clear  definition  of  need  must  be  established.  This 
discussion  is  about  "Medical  Need"  tMiich  are  services  required  to  attain  or  maintain  health. 
This  part  of  the  process  module  contains  a  madiematical  model,  commonly  called  an  actu¬ 
arial  model,  which  can  forecast  morbidity  for  die  population  of  interests.  This  model  fore¬ 
casts  morbidity  for  the  population  in  question  based  on  historical  information  firom  a 
mmilar  population.  Before  the  need  can  be  established  ,  a  desired  level  of  health  must  be 
determined  for  the  population.  Source  of  data  will  include  die  Epidemiological  Data, 
Health  Promotion  Guideline  and  Proxies.  Once  die  level  of  health  has  been  established, 
die  morbidity  data  can  be  turned  into  services  required  to  meet  die  need.  Exanqdes  of  the 
services  projected  during  dus  step  in  die  NHCSPP  are  mmiber  of  eiqiected  live  birdis, 
number  of  iqypendectomies,  and/or  the  number  of  tonsillectomies. 
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While  waitiine  medical  planners  have  traditicmally  dealt  with  metUcal  need  in  tenns  of 
moitndity  [Ref  1],  peacetime  health  care  planners  have  been  limited  in  dieir  ability  to  fuDy 
address  medical  need.  As  a  result,  addressing  need  will  not  be  an  easy  task.  The  Navy 
Medical  Department  has  begun  to  assemble  a  body  of  literature,  data  sources,  and  informa¬ 
tion  on  models  available,  as  well  as,  tools  that  will  allow  the  health  care  planner  to  accom¬ 
plish  this  process. 

D.  ASSESS  THE  DEMAND 

Once  a  sound  demographic  profile  has  been  developed,  the  planner  can  begin  to  access 
demand.  Demand  c<nisists  of  diree  components;  met  demand,  customer  expectation  and 
where  the  care  is  being  provided  [Ref  6].  Met  demand  is  that  level  of  care  currendy  being 
provided.  Cushmier  expectations  are  r^t  die  customer  expects  fi-om  the  health  care  sys¬ 
tem.  Where  the  care  is  being  provided  factors  into  the  question  of  where  to  establish  the 
different  health  care  services.  Once  die  met  demand  and  die  customer  eiqiectations  are 
identified,  then  the  difference  between  diese  two  values  can  be  calculated.  This  variance 
should  be  analyzed  to  identify  differences  between  met  demand  and  expectations,  like  bar¬ 
riers  to  access  previously  mentioned  or  odier  constraints  on  availability.  The  anafysis  of 
variance  win  aUow  the  planner  to  reach  an  estimate  of  the  services  required  to  meet  the  ac¬ 
tual  demand  for  health  care  services. 

E.  DETERMINE  THE  REQUIREMENT  FOR  HEALTH  CARE  SERVICES 

Now  that  the  planner  knows  vriiat  services  are  ncccssaiy  to  meet  the  medical  need  and 

die  demand,  he/she  must  compare  die  two,  du-ough  an  analysis  of  variance.  The  analysis 
of  variance  during  die  different  step  of  die  process  is  very  important.  It  enables  huge 
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bodies  of  data  to  be  condensed  into  useful  information.  It  also  stresses  to 

decisions  with  die  objective  of  getting  die  {vocess  "in  control".  Once  die  reason  or  reasons 
for  vanance(s)  is  identified,  the  planner  may  dien  use  this  information  to  determine  how  to 
estimate  the  total  requirement  for  healdi  care  services.  After  needs  and  demands  have  beoi 
carefully  examined,  smoodung  techniques  may  dien  be  apjdied  dependent  upon  the  popu- 
ladon  of  interest. 

F.  FORECAST  THE  RESOURCE  REQUIREMENT 

Now  diat  the  planner  has  an  idea  of  the  total  health  care  services  required  to  meet  the 
needs  of  die  specified  population,  it  is  possib’^  to  match  resources  to  those  services  and 
forecast  die  total  resource  requirement  to  meet  the  medical  need.  Resource  requirements 
include  maiqiower,  money  and  material.  The  planner,  using  qiecified  stafEmg  and  costing 
standards  and  guidelines  developed  with  die  assistance  of  BUMED,  will  be  aUe  to  finecast 
a  total  resource  requirement. 

An  initial  effort  has  been  made  on  the  issue  of  staffing  standards  and  costing  modes 
with  die  development  of  clinical  specialty  plans,  the  efficiency  review  process  and  health 
care  requirements  matrix.  Care  must  be  taken  because  these  efforts  have  been  "(me 
dimensional”  in  diat  they  have  primarily  addressed  manpower.  There  is  a  need  to  iqidate 
and  expand  these  efforts.  The  location  of  die  care  to  be  provided  and  the  actual  means  by 
which  the  care  will  be  delivered  are  discussed  in  a  later  in  die  chapter.  These  changes  re- 
(juire  the  plaimer  to  look  outside  die  traditional  paradigm  of  providing  care  in  his/her  own 
facilities. 
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G.  BEGIN  THE  PLAN  DF  OPMENT 


Once  the  total  resources  required  to  meet  the  entire  health  care  need  for  die  particular 
catchment  area  are  determined,  the  health  care  planner  can  begin  develofnng  a  plan  to  {vo- 
vide  that  care.  The  planner  must  identify  aO  the  available  resources.  Speci%ally,  the  plan¬ 
ner  must  identify  the  providers  and  the  support  stafis,  the  doQars  and  facilities  available  and 
any  external  such  as  exiting  partnerships  and  contracts  that  may  be  of  use  The  dollars 
here  consist  of  these  for  direct  care  and  for  CHAMPUS  |»ovided  care.  This  inventory  is 
tfien  compared  widi  the  resource  requirement,  and  the  difTerence  represents  the  unfunded 
or  unmanned  requirement.  The  factms  of  cost,  quality  and  access  must  be  analyzed  with 
catchment  area  managers  and  priorities  determined  for  die  defdoyment  of  resources. 

H.  DEVELOP  ALTERNATIVE  DELIVERY  STRATEGIES 

In  developing  ahemate  delivery  strat^es,  die  plarmer  roust  use  the  tools  provided  by 
die  BUMED  Strategic  Plaruiers.  The  question  facing  die  planner  is  how  can  die  resources 
available  (dollars,  material  and  maiqxiwer)  be  better  used  to  meet  more  of  die  medical 
need.  The  health  care  planner  must  use  standard  staffing  and  costing  models  to  estimate 
die  cost  for  setting  up  alternative  delivery  strategies.  The  plarmer,  then  will  use  an  environ¬ 
mental  assessments  and  catchment  area  capabilities  assessments  to  develop  a  list  of  ahema- 
tives  based  on  die  established  priorities.  The  environmental  assessment  tool  forces  a 
catchment  area  plarmer  to  look  at  all  factors  external  to  the  health  care  system  \^ch  may 
impact  the  wi^  services  are  provided.  The  c'ltchment  area  capabilities  assessment  causes 
die  plarmer  to  take  a  hard  look  at  afl  means  of  healdi  care  services  delivered  in  the  catch¬ 
ment  area,  ndiether  under  the  direct  control  of  the  catchment  area  manager  or  not.  This  is 


31 


a  complete  assessment  of  providers,  facilities  and  health  programs  in  die  rjuftimpfit  area. 
This  step  is  critical,  in  that  it  recognizes  die  direct  and  indirect  influences  of  all  health  care 
abematives  in  the  catchment  area  system.  It  is  inqiortant  to  note  diat  the  use  of  these  tools 
is  part  of  a  planner's  first  duty  in  planning,  along  with  the  establishment  of  a  baseline  for 
internal  and  external  resources  developed  from  a  diorough  examination  of  die  environ* 
ment.  While  this  information  may  not  be  actually  used  ip  the  planning  r  .ediodology,  diis 
baseline  reference  will  be  continuously  iqidated  and  improved  with  use.  This  demonstrates 
the  iterative  nature  of  the  model,  and  the  fact  diat  the  planner  is  not  tied  to  one  particular 
starting  point. 

Following  die  consideradon  of  internal  and  external  factors  influencing  the  allocation  of 
available  resources  to  meet  the  forecasted  heald:  care  services  requirements,  the  plarmer 
wfll  develop  alternatives  addressing  the  total  requirement.  Make*Buy  models  will  help  die 
plarmer  in  developing  and  correlating  costs  of  any  delivery  alternatives.  The  ability  to  cost 
out  delivery  alternatives  will  allow  the  plarmer  to  identify  die  marginal  cost  of  health  care 
services.  The  result  of  this  process  is  a  set  of  alternatives  of  varying  cost  and  benefit  that 
meet  the  totality  of  the  requirement. 

I.  SELECT  THE  ALTERNATIVE  FOR  IMPLEMENTATION 

The  catchment  area  manager  is  positioned  to  examine  comparable  ahematives,  each 
having  been  developed  by  a  common  process.  This  process  can  dien  consider  a  complete 
examination  of  all  relevant  factors,  widiout  prejudice  of  site,  of  care,  or  source  of  provider. 
An  ahemadve  can  be  selected  and  implemented  widi  the  knovdedge  that  decisions  have 
been  made  using  the  best  information  available,  and  that  future  evaluations  will  highlight 
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oppmtumtks  for  inq>rovement.  At  die  local  level,  a  primaiy  objective  of  die  process  is  to 
address  cost,  quality,  access  factors  affecting  health  care  dehveiy  and  to  identify  local  alter¬ 
natives  diat  may  increase  the  effectiveness  of  the  system.  Thus,  the  first  responsibility  of 
die  local  commander  wfll  be  to  seek  ways  to  repriontize  and  to  seek  local  solutions.  Failing 
dus,  a  furdier  product  of  each  attemative  is  die  identification  of  any  unfunded  require¬ 
ments.  This  provides  a  multi|dicity  of  vahiabte  information  that  may  be  used  in  siqipoit  of 
die  planning,  programming  and  budgeting  cycle. 

The  NSHCPP  represents  a  major  paradigm  shift  in  bodi  our  attitude  and  qiproach  to 
planning.  It  has  shifted  fi-om  a  siq>ply-side  medical  system,  driven  by  inliat  Navy  Medical 
can  {Movide,  to  a  requirements-based  system,  driven  by  our  customers'  healdi  care  needs 
and  desires.  This  top-down,  bottom-up  proc^  embraces  the  philosophy  of  Total  Quality 
Leadership  by  demanding  a  clear  statement  of  the  issue,  basing  decisions  on  objective 
analysis  of  common  data  and  allowing  for  local  flexibility  to  meet  unique  requironents.  Fi¬ 
nally,  die  planning  process  forces  Navy  Medicine  to  identify  die  total  requirement  for 
health  care  services,  and  to  seek  the  most  cost-effective  and  beneficial  means  of  delivery, 
using  die  maiginal  cost  sqiproach.  In  an  environment  of  steadily  declining  resources,  iden¬ 
tification  of  the  total  health  care  requirement  is  essential  in  providing  Navy  and  DOD  lead¬ 
ers  widi  die  information  diey  require  to  make  die  decisions  on  how  best  to  meet  the  health 
care  requirements  of  their  beneficiaries.  The  next  cluqrter  discusses  die  Navy  Medical  Ex¬ 
ecutive  Information  System. 
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V.  THE  NAVY  MEDICAL  EXECUTIVE  INFORMATION  SYSTEM 


The  Navy  Medical  Executive  hif<»inali(Hi  System  (EIS)  is  a  aystem  designed  to 
fMOvide  timely  and  accurate  information  to  Navy  Medical  executives  and  managers  who 
make  major  decisions  concerning  die  Jlocalion  of  resources  and  die  qieradon  of  health 
services  fscihties.  The  Navy  Medical  EIS  current  siq;)p]ies  health  care  executives,  ana¬ 
lysts  and  facility  managers  with  information  pertaining  to  workload,  cost,  and  personnel  in 
bodi  graphic  and  report  formats.  These  varied  formats  may  dien  be  used  for  analyzing 
current,  historical  and  projected  dqiabilities  of  oiganizational  operations.  The  design  of  the 
EIS  is  based  on  twelve  major  business  functions  idoidfied  as  critical  for  die  successful 
management  of  die  Navy  health  care  deHvray  system.  The  Navy  Medical  EIS  incoiporates 
standard  performance  measurements  defined  by  BUMED  and  DOD.  These  performance 
measurements  are  used  to  track  successful  resource  ailocation,  as  well  as  identify  possible 
problem  areas.  The  twelve  business  fimctions  are: 

1.  Conduct  Health  Care  Planning 

2.  Manage  Human  Resources 

3.  Manage  Finances 

4.  Maiu^  Education  and  Training 

5.  Provide  Health  Care  Siqiport  to  Operation  Forces 

6.  Provide  Health  Care  Though  Fixed  Facilities 
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7.  Manage  Departniait  of  the  Navy  Medical  and  Dental  Quality  AMurance  (QA) 
Program 

8.  Manage  Informatim  Resources 

9.  Provide  Medical  Administrative  Services 

10.  Provide  Procurement  and  Contracting  for  Climcal  Services 

11.  Manage  Physical  Resources 

12.  Perform  Medical  Research  and  Development  [Ref  7] 

Each  of  diese  twelve  (12)  business  futtcti<»s  are  separate  and  dtstinct  modules  of  die  EIS 
with  separate  functional  users.  Therefore,  each  OKxhile  has  its  own  unique  st)1e  of  ouqnit, 
performance  measures  and  uses.  As  a  result,  the  following  discussion  will  ranain  gaiaric 
in  r^;ards  to  die  ou^nits,  performance  measures  and  uses.  Below  is  a  discussion  of  eadi 
of  die  twelve  (12)  modules  [Ref  8]: 


1.  Navy  Health  Care  Strat^c  Planning  Process.  This  module  is  designed  to  be  used  by 
die  health  care  planner.  It  provides  assistance  in  the  following  areas:  make-buy 
evaluation  of  alternative  health  care  deliveiy  sources,  assessment  and  comparison  of 
need  and  demand,  arudysis  of  population  and  forecasting  resource  requirements,  hi 
addition,  dns  module  contains  actuarial  and  stafBng  models  to  support  the  decision 
making  process.  This  module  is  being  address  in  dds  diesis. 

2.  Human  Resources.  This  module  is  designed  to  assist  in  die  mani^ement  of  the  mili- 
taiy  and  civilian  persoimel.  It  assists  in  die  devdo|»nent  and  numagen^  of  man¬ 
power  allowances,  status  of  Medical  Department  pmonnel  (location,  end*etrengdi, 
recruitment,  accessions,  retirements,  releases,  qualifications,  privfleges,  certifications, 
education,  etc.X  (aviUan  petsormel  programs,  career  planning  programs,  physical 
qualification  standards,  medical  boards  and  temporary  active  duty  assignments.  This 
module  also  provides  assistance  die  maintaiance  of  flag  and  general  officer  medical 
records.  This  module  is  underdevelopment. 

3.  Manage  Firuoices.  Thh  module  is  deagned  to  be  used  by  conqiPoIlerB.  It  assists  die 
conqitroller  in  die  development  of  die  budgets,  distributiQn  and  control  of  funds  and 
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funds  (Section  programs.  AdditionaO)',  this  modules  provides  financial  management 
procedures,  and  provides  a  mediod  of  monitoring  budget  execution. 


4.  Education  and  Training.  Hus  module  is  designed  to  assist  in  die  management  of  the 
education  and  training  programs.  These  programs  include  Graduate  Medical  Educa¬ 
tion,  Out-Service  Training,  Leadership  and  Maiu^iement  Education  and  Training 
(LMET)  and  odier  specudized  training  programs.  Additional^,  it  assists  widi  die  as¬ 
signment  of  course  quotas  and  the  maintenance  of  training  records.  This  module  is 
currendy  in  die  design  phase. 

5.  Health  Care  Siqiport,  Operational  Forces.  This  module  is  designed  to  provide  opera¬ 
tional  support  to  the  fleet  and  United  States  Marine  Corps  (USMC)  units  (includes 
personnel,  technical  information,  identification  of  medical  research  and  development 
needs  and  logistics  suppcnt).  It  is  designed  to  assist  in  the  management  of  medical 
readiness,  contingency  and  mobilization  activities.  Additional^,  it  assists  widi  die  co¬ 
ordination  of  medical  intelligence  and  international  standards  and  is  used  to  die  de¬ 
velop  Navy  Medical  Doctrine. 

6.  Healdi  Care  through  Fixed  Facilities.  This  module  is  designed  to  assist  in  die  man¬ 
agement  of  ahernadve  healdi  care  delivery  sources,  occupational  health  and  safety 
programs,  medical  and  dental  programs  (e.g..  Blood  program,  HIV,  Famify  Advo¬ 
cacy,  Dn%  and  Alcohol  Abuse  and  Dental  Insurance)  and  Disaster  Prqiaredness. 
Additionally,  it  is  used  to  provide  assistance  with  the  assessment  of  performance,  ac¬ 
creditation  of  MTFs,  development  and  enforcement  of  medical  and  dental  care  stan¬ 
dards  and  deliveiy  of  health  care  to  all  eligible  beneficiaries.  This  module  is  under 
development. 

7.  Medical  and  Dental  Q/A  Program.  This  module  is  designed  to  assist  in  the  develop¬ 
ment  of  medical  and  dental  quality  assurance  (QA)  policies,  procedures  and  pro¬ 
grams  for  the  Department  of  die  Navy  (DON).  It  is  used  to  provide  assistance  in 
monitoring  die  status  of  medical  and  doital  QA  programs  for  DON  and  medical  and 
dental  QA  activities  at  MTF/DTF  and  odier  &ed  facilities.  Also  dns  module  pro¬ 
vides  technical  medical  and  dental  QA  advice  to  DON  conqionents.  This  module  is 
under  development. 

8.  hiformaticni  Resources.  This  module  is  designed  to  assist  die  Mam^ement  Informa¬ 
tion  System  (MIS)  personnel.  It  provides  assistance  with  the  management  of  infor¬ 
mation  resource  programs  as  well  as  die  development  and  implementation  of 
information  systems.  Additionally,  this  module  assists  die  MIS  personnel  widi  die 
operation  and  maintenance  of  existing  information  qrstems.  This  module  is  under 
development. 

9.  Administrative  Services.  This  module  provide  assistance  with  correspondence  control 
bodi  internal  and  external  Additionally,  it  assists  in  the  management  of  inspections. 
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intemal  review  and  control  maters,  public  affairs  program,  l^al  services,  as  wdl  as 
tfie  Morale,  Welfare  and  Recreation  (MWR)  program. 


10.  Procurement  and  Contracting.  This  module  is  designed  to  assist  the  procurement 
and  contracting  personnel.  It  provides  assistance  with  the  development  of  contractual 
statements  of  work  and  evaluation  {dans  and  tfie  monitoring  of  existing  contracts. 
Additionally,  it  provides  technical  etqxrtise  in  procumnent  and  contracting  areas. 
This  module  is  under  development 

11.  Physical  Resources.  This  module  is  designed  for  facility  matugere  as  well  as  die  lo¬ 
gistician.  It  provides  siqiport  with  the  corndination  of  medical  logistics  and  nuderial 
si^iport  to  die  operating  forces.  Also,  this  module  assists  in  die  design,  acquisition 
and  maintenance  of  medical  and  dental  facilities  and  management  of  biomedical 
and  dental  equqmient  and  siqiplies.  This  module  is  undo^  devdopment. 

12.  Research  and  Develo(nnent  This  module  is  designed  to  assist  the  research, 
development,  testing  and  evaluation  manager.  It  provides  assistance  with  the  review, 
definition,  priorization  and  monitoriiig  of  research  and  devdopment  programs  and 
requirements.  Additionally,  diis  module  assists  in  the  review  of  operational  infoima- 
tion  for  medial  research  and  development  (R&D)  inqilication  as  well  as  the  partici¬ 
pation  in  inter-service  medical  R&D  and  standardization  programs. 


The  Navy  Medical  EIS  objective  are: 


•  To  provide  a  single  source  of  information  that  is  reliable,  timely  and  accurate  concern¬ 
ing  health  care  dehvay  fi-om  BUMED  to  the  facility  level. 

•  To  provide  the  non-technical  executive  a  PC-based  system  which  provides  rapid,  user- 
fiiendty  access  to  information  pertaining  to  peifoimance,  resource  utilization  and  criti¬ 
cal  success  factors. 

•  To  display  information  on  a  color  monitor  in  report  and/or  grrqihic  format. 

•  To  build  die  system  around  die  following  design  concepts: 

■  Exception  based  reporting 

■  Commercial-off-the-shelf  (COTS)  software  (buy  vs.  build) 

■  Phased  implementation  dirough  rqtid  prototype  development  and  deployment 

■  Maximized  return  on  investment 

■  Hectronic  distribution  of  updated  information 
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•  To  provide  siq>pof1  to  the  Coordinated  Care  Program  (CCP)  initiative  by  devdopii^  a 
Make  vs.  Buy  Model  utiluing  Civilian  Health  Care  and  Medical  Program  of  the  Uni¬ 
formed  Services  (CHAMPUS)  and  other  resources  and  workload  information  to  assist 
commanders  in  providing  cost  effective,  quality  health  care  in  a  prcmipt  maimer.  [Ref 
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The  functional  requirements  of  the  Navy  Medical  £IS  are; 

•  To  provide  top  level  executives  with  rapid  reliable  information  on  key  performance  in¬ 
dicators  and  critical  success  factors  to  aid  in  the  determinatiQn  of  effective  use  of  re¬ 
source  allocation  and  management.  As  such,  provide  a  mechanism  to  measure  goal 
attaiiunent  in  support  of  Total  Quality  Leadodti^  (TQL)  in  die  CCP  environment. 

•  To  present  information  in  a  user-fiiendly,  non-technical,  easily  accessed  PC-based 
environment. 

•  To  present  information  in  both  report  and  color  graphic  formats  widi  drill  down  and 
moiling  based  capabilities.  [Ref.  7] 

The  immediate  benefit  of  die  Navy  Medical  PIS  is  its  ability  to  provide  managers  of  all 
fimctional  areas  within  die  Nsvy  Medical  Department  with  information  and  ana^lical  tools 
necessary  to  make  informed  decisions  concerning  the  allocation  and  management  of  scarce 
resources.  It  enables  health  care  executives,  analysts,  planners  and  managers  to  more  read- 
ify  identify,  understand,  and  track  issues,  performance  measures,  problems  and  opportuni¬ 
ties  in  a  timely  manner  without  volumes  of  paper  reports.  The  EIS  provides  issue-oriented 
information  which  supports  better  communication  and  coordination  for  tighter  control, 
timely  intervention  and  informed  decision  making.  This  system  allows  die  Navy  healdi 
care  manlier  to  analyze  historical  data  as  wed  as  current  trends  in  order  to  estimate  future 
resource  requirements  required  to  support  management  goals,  strat^es  and  objectives. 
The  system  may  also  be  used  to  aid  in  the  evaluation  of  "cause  and  effect"  rdatirmships  of 
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both  past  and  prcqxwed  decisions.  The  successful  inq>lementatkm  of  Navy  Medical  EIS 
wfll  position  the  Navy  heatdi  care  iM*oviders  in  a  leading  position  for  transitiQn  into  the  new 
DOD  environment  of  Coordinated  Health  Care.  [Ref.  7] 

The  Navy  Medical  EIS  wiD  provide  die  users  direct  access  to  data  generated  frcnn  a 
sin^e  source  for  die  twelve  major  functional  areas  of  responsibility  for  the  executive  man¬ 
agers  of  die  Navy  Medical  Department.  Anticipated  benefits  of  the  Navy  Medical  EIS 
include: 

•  Improved  management  efTectiveness 

•  Reduced  CHAMPUS  costs 

•  Better  use  or  controlled  growth  of  existing  Navy  hospitals  and  clinics 

•  hiQiroved  readiness 

•  State-of-die-art  quality  health  care 

•  Inqnoved  beneficiaiy  services 

•  Potential  tii-service  apjdication  to  support  die  CCP  through  a  standardized  interoper¬ 
able  information  management  system.  [Ref.  7] 

The  real  value  of  the  Navy  Medical  EIS  comes  fi-om  the  ^eigy  provided  by  the  incor¬ 
poration  of  die  twelve  functional  area  modules  and  their  defined  performance  measures, 
resulting  in  a  wealth  of  integrated,  issue-oriented  mam^ement  information.  This  system 
offers  a  fundamental  change  in  die  way  health  care  services  may  be  managed  in  die  Navy. 
The  advantages  of  an  executive  infoimation  system  such  as  die  Navy  Medical  EIS  win  be 
realized  by  permitting  health  care  managers  to  idmtify  opportunities,  manage  benefits  and 
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measure  patterns  for  successful  delivery  of  services.  Executives,  analysts,  j^annos,  and 
managers  can  access  a  wide  range  of  rqx)rts  and  gr^^  diqdays  showing  status,  trends 
and  exceptions,  to  bodi  monitor  and  forecast  (»ganizational  performance.  As  Ae  EIS  is 
implemented,  it  win  provide  a  basis  for  health  care  plaiming  and  an  opportunity  for  im¬ 
proved  deliveiy  of  healtfi  care  services.  As  such,  it  wfll  provide  the  foundatirm  for  central¬ 
ized  control  and  decentralized  execution.  [Ref.  7] 

A-  HAW)WARE  ARCHITECTURE 

The  current  Navy  Medical  EIS  requires  the  use  of  an  IBM-conq>atiUe  processor  (Am¬ 
dahl  3090/190E).  Data  required  for  reporting  and  modeling  is  stored  within  the  EIS  main¬ 
frame  COTS  software.  This  data  is  transferred  into  die  EIS  from  existing  Navy  and  other 
medical  information  management  systems  extomal  to  die  EIS,  (i.e.,  Medical  Expmse  and 
Performance  Rqiorttng  System  (MEPERS),  Quahly  of  Care  Evaluation  System 
(AC^CESS),  Composite  Health  Care  System  (CHCSX  Defense  EligibOity  EnroOmenl  Re¬ 
porting  System  (DEERS)).  User  access  to  the  mainframe  data/rqiorts  and  models  is  pro¬ 
vide  via  die  Medical  Open  Architecture  (MED-OA)  netwoilc.  User  PCAVorkstation  with 
COTS  application  software  components  are  tightly  coupled  to  the  COTS  mainframe-based 
application  software  components  of  the  EIS,  as  diey  are  vendor  specific  and  conununicate 
in  an  iqiplicadon  to  application  dialogue. 

B.  OPERATING  SYSTEM 

The  current  Navy  Medical  EIS  host  supervisory  and  utility  software  is  die  IBM  MVS 
and  VM  operating  systems  and  arc  provided  by  IBM.  The  PC/Worlcstation  operating  sys¬ 
tem  is  Xficrosoffs  DOS,  provided  by  die  PC  supplier.  Miniconqiuters  and  LAN  servers 
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thnH]sjhM>ut  die  MED-OA  netwoik  used  by  die  Navy  Medical  EIS  are  controlled  by  a 
UNIX  operating  system. 

C.  COMMUNICATION  SYSTEMS 

The  Navy  Medical  EIS  host  inter&ce  includes  bodi  local  and  ranote  LANs  networked 
by  DDN  and/or  Navy  Host  Concenlratoiy  (NAVNET)  iqigrades  in  addition  to  local  and 
remote  dial-iqi.  Use  of  DDN  and  NAVNET  dial-iq>  as  a  replacement  to  ranote  dial  -iq)  is 
under  investigation 

The  Navy  Medical  EIS  user  interface  is  inovided  by  a  local  and  remote  (dial-up)  PC  or 
a  LAN-based  PC/Workstation.  The  COTS  software  is  DOS-based  and  is  used  in  bodi 
stand-alone  and  host-attached  modes.  Batch  file  transfer  (reports,  screens,  models)  and  in¬ 
teractive  inodes  are  required.  Thoi^  not  currai^  used,  the  uqMbility  for  usos  to  geno-- 
ate  SQL-based  requests  for  data  to  remote  locations  is  avatlaUe. 

The  Navy  Medical  EIS  host  system  runs  maiiy  qiplications  in  a  multi-user,  multi¬ 
programming  MVS  environment,  and  requires  additional  communicatim  access  software 
and  hardware.  The  immaiy  host-based  software  is  Virtual  TelecoromunicatiQn  Access 
Method  (VTAM),  which  provides  a  single  pdnt  of  tdecommunications  access  numage- 
ment,  and  Network  Control  Program  (NCP)  which  provides  die  VTAM  access  to  die  net¬ 
work  control.  Additional  units  of  software  and  hardware,  external  to  die  host,  are  required 
to  provide  necessary  protocol  convosions,  gateways  and  switching  controls. 

D.  DATA  SOURCES 

The  Navy  Medical  EIS  uses  data  sources  fiom  widiin  and  external  to  the  host  Various 
standard  Navy  and  DOD  Medical  systems  collect,  process  and  store  data  widun  the  host's 


ADABAS  Data  Base  Management  System  (DBMS).  Hie  two  langiu^fae  used  to  extract 
data  from  ADABAS  are  Natural  and  Siq)ematural.  For  data  located  at  other  locations  a 
multiplicity  of  automated  and  manual  means  are  used  to  transport  data  to  die  NMIMC. 

E.  APPLICATION  SECURITY 

Navy  Medical  EIS  users  and  developers  must  first  provide  an  audioiized  system  level 
^entificadon  code  and  password  for  access  to  the  NMIMC  syr  sms.  Access  to  documents 
widiin  die  Navy  Medical  EIS  (reports,  graphic  screens,  etc.)  are  also  controDed  t>y  a  User 
ID.  The  EIS  System  Administrator  is  authorized  to  assign  and  manage  EIS  iimctions  by 
User  ID.  The  Navy  Medical  EIS  PC/Workstadon  also  has  the  ability  to  lock  the  keyboard 
which  requiies  die  user  to  see  die  System  Administrator  to  regain  access. 

F.  APPLICATION  SOFTWARE 

The  commercial-ofiT-die-shelf  (COTS)  software  used  for  the  Navy  Medical  EIS  uses 
interlinked  licensed  modules  from  Comdiare,  Inc.  Arm  Arbor,  h/fichigan.  Comshare's  pri¬ 
mary  business  is  EIS  software  and  diey  are  one  of  the  leading  vendors  of  diis  type  of  soft¬ 
ware.  Comshare's  mainframe  components  provide  data  management,  model  management 
and  workstation  management  functions.  Systems  buflders  use  an  internal  Application  Defi¬ 
nition  Language  (ADL)  to  initiate,  automate  and  control  EIS  functions. 

Additional  nuiinframe  conyionents  utilized  by  the  Navy  Medical  EIS  include  an  IBM 
compatible  DBMS  and  an  E-Mail  system.  Currently,  ADABAS  fixnn  Software  A.G.  (run¬ 
ning  under  the  MVS  operating  system)  and  PROFS  (miming  under  die  Virtual  Mru^hine 
(VM)  operating  system)  fiom  IBM  provide  diese  functions. 
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Navy  Medical  EIS  users  are  provided  an  off-line  PC/W(»kstati(»i  ciq)alHlity  to  review 
briefing  books  containing  reports  mi/ot  gr^hics  (prepared  in  advance,  automatically  up¬ 
dated  at  the  mainfirame  and  sent  to  die  PC/Workstation  monthly  via  usernnitiated  update 
process)  and  import  or  eiqiort  files  to  other  locally  used  PC  software.  While  connected  to 
die  matnfiame,  the  user  can  anafyze  and  review  (in  repmt  and/or  g^rqidikal  format)  differ¬ 
ent  views  of  17  to  a  nine  dimensional  model. 

G.  USERS  PROFILE 

The  Navy  Medical  EIS  primary  focus  is  to  serve  the  needs  of  the  top  (hiec  (3)  levels 
of  the  Navy  Medical  Organization,  (1)  Top  level  Navy  executives,  (2)  Bureau  of  Medicine 
and  Surgery  (BUMED)  and  Headi  Service  Organization  (HSO)  health  care  analysts,  and 
(3)  fadlity  maru^ers.  User  pmonnel  at  each  of  diese  organizational  levds  ate  line  manag¬ 
ers,  fifflctional  managers,  executive  assistants,  and  functional  analysts.  The  EIS  can  spe¬ 
cifically  tailor  information  for  each  individual  user,  and  users  can  also  create  and  save 
"personalized"  informational  views  to  meet  his/her  specific  needs. 

j 

i 
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VI.  FUNCTIONAL  DESCRIPTION  OF  THE  NAVY  HEALTH  CARE 
STRATEGIC  PLANNING  PROCESS 

A  Functional  De8ci'q>tion  (FD)  is  nonnally  prqMred  for  aay  system  that  rcqui^  a  ba¬ 
sis  for  mutual  understanding  between  die  developmral  group  and  the  uso*  grm^  of  the 
proposed  system.  It  defines  d.e  system  as  well  as  the  system  requiremaits  and  provides  the 
users  with  a  clear  statement  of  die  operadmial  capability  to  be  developed.  If  the  scope  of 
die  FD  is  changed  at  any  point,  the  FD  should  be  updated  and  user  concurrence  received. 
(Ref.  9] 

The  FD  is  a  tool  for  use  by  both  computer  and  noncooqiuter-oriented  personnel.  It 
shorM  be  written,  as  much  as  possiUe,  in  noncomputer-oiiented  langu^,  since  many  ele¬ 
ments  of  the  document  will  be  subject  to  review  by  staff  personnel  who  do  not  necessaril)' 
have  a  conqiuter  background.  The  following  sections  discuss  die  layout  of  the  FD  based 
on  reference  9,  after  ^bich  an  actual  draft  FD  of  the  NHCSPP  is  presented. 

A.  FUNCTIONAL  DESCRIPTION  REQUIREMENTS 

When  developing  a  FD  that  meets  the  requirements  of  die  DOD,  the  DOD  Standard 
for  Automated  Data  Systons  Documentation  (DOD-STD-793SA)  [Ref  8]  is  used  as  the 
basis  for  development.  DOD-STD-793SA  requirements  are  midined  in  the  following 
sections. 

1.  General 

This  section  contains  general  mfonnation  concerning  the  syston  to  be  developed 
and  is  made  iqi  of  the  following  sub-sections. 
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«.  Purpote  of  the  FuneHotui  DeseriptioH 

This  sub-section  describes  the  purpose  of  die  FD,  as  required  by 
DOD-STD-7935A  [Ref  8]  is: 

This  Functional  I>escription  for  (Project  Name)  (Project  Number)  is  written  to 
jMovide: 

•  The  system  requirements  to  be  satisfied  which  will  serve  as  a  basis  for  mutual  under¬ 
standing  between  the  user  and  die  developer. 

•  Information  on  performance  requirements,  preliminary  design,  and  user  impacts,  in¬ 
cluding  fixed  and  continuing  costs. 

•  A  basis  for  the  development  of  system  tests.  [Ref.  8] 

b.  Project  References 

This  sub-section  provides  a  brief  summary  of  the  references  applicable  to  the 
history  and  development  of  die  project.  The  general  lurture  of  the  computer  programs 
(tactical,  inventory  control,  war  gaming,  maruigement  information,  etc.)  to  be  developed 
shall  be  specified.  The  project  qxmsor,  user  and  operating  ccnteT(8)  that  will  run  the  com¬ 
pleted  computer  programs  shall  be  identified. 

The  following  documents,  wdien  applicaUe,  are  required  to  be  specified  by  author 
or  source,  reference  number,  dde,  data  and  security  classification: 

•  Project  request,  a  copy  of  wdiich  must  be  included  as  an  ^ipendix. 

•  Previously  developed  technical  documentation  relatittg  to  this  project 

•  Significant  correspondence  relating  to  die  project  to  include  formal  agreements  to  the 
requirements  contained  in  die  FD. 

•  Documentation  concerning  related  projects. 

•  Other  manuals  or  documents  that  cmistrain  or  explain  technical  factors  affecditg  iMt>- 
ject  development 


•  Standard  or  reference  documentation,  such  as: 

■  Documentation  standards  and  spedficaticHis 

■  Programming  conventions 

■  DOD  or  Federal  standards  (data  elements,  programming  languages,  etc.) 

■  Hardware  manuals,  support  system  documentation,  etc.,  if  necessary,  for  an 
understanding  of  the  FD. 

When  apidicable,  specific  reference  should  be  truule  to  die  provisions  of  these  documents 
in  subsequent  sections  of  the  FD. 

e.  Terms  and  Abbreviations 

This  sub-section  shoidd  contain  a  listing  to  include  an  iqipendix  of  terms, 
definitioos,  or  acronyms  unique  to  this  document  and  subject  to  interpr^ation  by  the  user. 
This  Esting  will  not  include  item  names  or  data  codes. 

2.  System  Summary 

This  section  provides  a  general  descr^don,  written  in  noncomputer  temiinol(^,  of 
die  existing  system  and  of  die  requirements  for  the  proposed  system.  This  section  includes 
die  following  sub-sections: 

a.  Background 

Licluded  within  dds  pars^aph,  as  necessary,  win  be  any  information  concern¬ 
ing  the  background  of  die  uses  and  purposes  of  die  system  to  orient  die  reader.  Reference 
must  be  made  to  higgler  order  and  paraHel  systems  when  needed  to  aihance  the  general  de- 
soiptioiL  Rdationshqis  between  the  project  and  other  ciqiabilities  to  be  developed  concur¬ 
rent  shaO  be  described. 
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b.  Objectives 

Statements  of  &e  majOT  performance  requirements  and  goals  of  the  proposed 
CQnq>uter  system  must  be  included.  These  statements  should  be  ctmcise,  quantified  if  pos¬ 
sible,  and  may  include  exanq>les.  When  appficaUe,  related  events,  such  as  exerc^  or  im¬ 
pending  military  operations,  nury  be  discussed.  Any  anticq>ated  opoatioiud  dumges  that 
win  affect  die  system  and  its  use  shall  be  identified  and  die  provisions  within  die  system  for 
including  them  shaO  be  explained. 

c  Existing  MeAods  and  Procedures 

This  sub-section  shall  provide  a  biwf  description  of  die  current  methods  and 
procedures  being  employed  to  satisfy  the  existing  information  requirements.  A  chart  must 
be  included  depicting  die  existing  data  flow  tfarou^  the  fimcdonal  ^rston  firom  data  acqui¬ 
sition  through  its  processiiig  to  eventual  ouqnit  This  chart  may  be  complemented  by  an 
e^qilanation  or  another  chart  showing  die  sequence  in  which  die  operational  fimctions  are 
performed  by  the  user  and  pointing  out  die  siqiport  provided  by  the  present  ^tem  for  de¬ 
cision  making.  Additionally,  die  fcdlowing  infinmation  at  a  minimum  should  be  include  in 
the  description: 

*  Organizadonal/persormel  responsibilities 

*  Equqmient  being  used 

*  hqiuts  and  outputs  including  volume  and  fioquency 

*  Deficiencies,  including  limitations,  such  as  time  delays 
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d.  Proposed  MeAods  and  Procedures 

A  descr^tion  of  ttie  |»x)po8ed  mediods  and  procedures  will  be  presoited  in  dus 
and  following  sub>sub-sections.  The  desci^tion,  written  in  nQncQnq)uter  teimuKdogy, 
should  e;q[)]am  how  the  proposed  system  will  interact  with  die  functional  processes  of 
which  die  automated  system  will  be  siqipordve.  When  other  functional  and  autinnated  sys- 
tons  win  be  used  with  or  will  become  part  of  die  proposed  system,  they  will  be  referenced 
in  dus  description. 

A  chart  depicting  the  proposed  data  flow  should  be  provided  to  present  an 
overall  view  of  planned  ciqiabitities.  If  the  proposed  system  eliminates  or  degrades  any  ca¬ 
pabilities  in  die  existing  system,  these  capabilities  must  also  be  described  as  well  as  the  rea¬ 
sons  for  their  etimination  or  d^radation.  Alternative  methods  and  procedures  that  have 
been  considered  may  be  included.  A  chart  showing  die  major  functional  processing  steps 
and  a  chart  showing  the  interacting  organizations  diould  be  included  within  the  following 
paragraphs  whenever  they  best  complement  the  narrative: 

(1)  Summary  of  Inqirovements.  This  sub-sub-section  provides  a  qualitative 
and  quantitative  summary  of  die  benefite  to  be  obtained  from  the  proposed  system.  A 
comparison  of  die  deficiencies  identified  in  the  "Existing  Methods  and  Procedures"  and  die 
identification  of  any  additional  crqiabSities  required,  along  with  appropriate  explanations, 
may  be  provided.  The  required  crqrabifities  diat  win  be  satisfied  by  the  proposed  system 
must  be  explietdy  identified. 

When  inqnovements  to  existing  mediods  and  procedures  are  a  requirement,  the  extent 
of  die  anticqiated  improvemoits  must  be  stated.  This  discussion  may  include: 
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•  functional  improvementg  (new  c^>abilities) 

•  inytovementa  of  degree  (iq>grading  exialing  capabilities) 

•  timdiness  (inqvoved  req^(mse  tm 

•  the  eliniination  or  reduction  of  existing  ciftabilities  tftat  are  no  kxiger  needed 

(2)  Sunmuay  of  bnpacts.  This  and  die  following  sub-sub-sections  shall  de¬ 
scribe  die  anticipated  impacts  and  associated  costs  die  proposed  system  wiD  have  on  die  or- 
ganizatiofial  and  operational  environment  of  die  user,  hiqiacts  on  die  user  during  die 
development  of  the  system  shall  also  be  noted. 

(a)  User  Organization  Inqiacts.  Qiganizatianal  inqiacts  may  indude  die 
modiBcations  of  reqxmsilMlities  and  die  addition  or  elimination  of  reqionsibililies  that  will 
be  necessary  to  use  die  prrqiosed  rystem.  Any  personnel  eliminated  will  be  identified  ar-»'<  a 
discussion  provided  of  die  possibilities  for  retraining.  Requirements  for  die  number  and 
skills  of  additional  posonnel  win  be  identified.  Indtuded  wffl  be  changes  in  authorized 
strength,  location  and  position  identifier,  if  known. 

(b)  User  Operational  hiqiacts.  The  operational  impacts  on  die  organizatirm 
during  die  use  of  die  proposed  system  wfll  be  included.  This  discussirm  wiD  consider  the 
proposed  interfiice  between  die  user  and  die  conqniter  (^lerating  center,  die  impacts  on  the 
user  to  change  fiom  die  current  operational  procedures,  new  data  sources,  quantity,  type, 
and  timeliness  of  data  to  be  submitted  for  use  in  the  system;  data  retendon  requiremaits; 
and  modes  of  user  operation  based  on  peacetime,  alert,  and  wartime  conditiofis.  Also 
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induded  will  be  proposed  mediods  for  provi^ng  ii^ut  duta  if  diese  dii*?  are  not  already 
available. 

(c)  User  Develofmient  Impacts.  Development  impacts  will  indutfe  a  dis¬ 
cussion  of  all  user  efforts  that  win  be  required  prior  to  implementation  of  die  syston.  Such 
as  training  and  die  nuuqxrwer  required  to  develop  or  modify  the  database,  etc..  This  sub- 
stib-section  must  include  ai^  user  requrements  for  paraOel  operation  of  die  ikw  and  exii>- 
ing  system  during  implementation  along  with  die  potential  impact  of  any  additional  activi¬ 
ties  to  be  provided  by  die  user  to  aid  in  devek^nnent. 

e.  Assmn^tions  md  Cenalrmnts 

This  sub-section  Shan  describe  any  user  assimqitions  and  constraints  that  win 
affect  development  and  operadrm  of  die  Qvtem.  Ariy  limitations  affecting  die  desired  ca¬ 
pability  (including  die  predication  of  esqiected  types  of  mors)  and  esqilidt  idendficatkm  of 
any  desired  crqiabilities  dud  wiU  not  be  provided  by  die  proposed  system  shad  be  discussed. 
Exaitqiles  of  assunqitions  include  organizational  actions,  budget  decisions  or  operational 
environment  and  deployment  requirements.  Exanqiles  of  constraints  include  operation  en- 
virorunent,  budget  limitations,  syi  **  m  inqilementation  deadlines  or  r^;ulatoiy  policy. 

3.  Detailed  Characteristics 

This  section  shad  provide  a  detailed  descr^on  of  die  pofomuuice  requirements  of 
die  proposed  system  written  in  noncmrqniter  terminology. 

A  Spedfie  Perfomumee  Requirements 

This  sub-section  shad  describe  die  specific  performance  requirements  to  be  sat¬ 
isfied  by  the  system.  This  presentation  shad  be  a  delineation  of  requirements  on  which  die 
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system  design  is  to  be  based  (anti(^>ated  deviations  from  any  of  die  standards  qiedfied  by 
die  documents  listed  the  "Project  References"  section  must  be  qiedficaDy  indicated).  The 
requirements  shaD  be  stated  in  such  a  manner  that  system  functions  discussed  in  die  Tunc- 
tional  Area  System  Functions”  sub-section  can  be  related  to  diem  as  well  as  system  testing 
requirements.  A  quantitative  presentation  of  these  requirements  wQl  be  included,  such  as 
die  number  of  records  diat  must  be  handled,  maximum  allowed  time  from  query  to  recent 
of  requested  information  and  flexibility  required  to  accommodate  changing  user 
requirements. 

(1)  Accuracy  and  Validity.  This  sub-section  shall  provide  a  descrqition  of  die 
accuracy  requirements  |daced  iqxMi  die  system.  The  following  items  must  be  considaed: 

•  accuracy  requirements  of  madiematical  calculations 

•  accuracy  requirements  of  the  data 

•  accuracy  of  transmitted  data 

(2)  Timing.  This  sub-section  shall  provide  a  descr^don  of  die  timing  require¬ 
ments  to  be  placed  on  the  system.  The  following  tuning  requirements  must  be  considered: 

•  response  time  from  receipt  of  iiqiut  data  to  availabiliy  of  the  system  ouqiut 

•  response  time  to  queries  and  to  updates  of  data  files 

•  secpiendal  relationship  of  functions 

•  priorities  inqiosed  by  types  of  inputs  and  changes  in  modes  of  operations,  and 

•  any  deviations  from  specified  response  times  for  peak  load  periods,  as  iqiplicable 

b.  Func6onal  Area  System  Functions 

This  sub-section  shall  amplify  and  describe  each  individual  function  of  the  ma¬ 
jor  functional  processing  steps  contained  in  die  "Proposed  Mediods  and  Procedures"  sub- 
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tectkxL  Tfatt  descnplion  ihoiild  rdate  flie  functioitt  of  die  pexfoanance  requremente  in 
die  "SpeciSc  Pofonnance  Requiranoils"  nib-section, 
e. 

This  sub-sectkm  shall  describe  each  data  dement  in  the  data  infNits  and  ouqnits 
from  die  i^stem.  The  fo&owingrequtranents  for  each  data  demoil  may  be  listed  infonna- 
tkm  such  as  die  following: 

•  data  donent  name 

•  Qmonymous  name 

•  defimtkm 

•  format 

•  range  or  enumeration  of  values 

•  unit  of  measure 

•  data  hern  name,  abbreviations  and  codes 

•  characteristics  sudi  as  precision,  accuracy,  timing  and  cqiadty 

When  the  information  is  published  in  a  data  element  dictionary,  refa«nce  to  an 
entry  in  die  dictionary  will  be  made  radier  dian  including  an  extract  from  diat  dictionary. 
Any  variatimis  in  eidia:  die  inputs  or  ouqnits  from  the  formats  or  data  item  names  diat  will 
be  toed  on  die  database  of  die  system  as  disciBsed  in  die  'Database  Charactmistics"  sub¬ 
section  must  be  spedficaOy  identified. 

When  svailal^,  die  various  irqiut  data  formats  shall  be  shown  and  nqmt  me¬ 
dium  (disk,  cards,  magnetic  tape,  analr^-or^rruUed  sepals  fnrni  revtdving  radar,  etc.)  diaD 
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be  q)ecified.  When  available,  ttie  various  ou^nit  data  focmats  including  any  quality  control 
outputs  dtsll  be  specified.  When  possible  these  outputs  should  be  rdated  to  die  systan 
fiinctions  described  in  the  "Functional  Area  System  Functions"  sub-section  above. 
d.  Database  Ckaraeterislics 

This  sub-section  provided  a  discussion  concerning  the  data  elements  to  be  used 
in  die  database.  Each  data  element  listed  may  contain  the  following  mfoimatian; 

•  data  element  name 

•  synonymous  name 

•  definition 

•  format 

•  range  or  enumeration  of  values 

•  unit  of  measure 

•  data  item  name,  abbreviations  and  codes 

•  characteristics  such  as  precision,  accuracy,  timing  and  capacity 

When  the  information  is  published  in  a  data  element  dicdonary,  reference  to  an 
entry  in  the  dictionary  will  be  made  rather  dian  including  an  extract  firom  that  dictionary. 
An  estimate  of  the  data  storage  requirements  in  terms  of  size  and  number  of  records  will  be 
provided.  A  description  of  die  expected  growth  of  die  data  and  rdated  conqionenlB  should 
also  be  provided. 
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e.  Fmbire  C»iUu^auus 


This  sub-section  diaU  prcfvide  a  discussion  of  ahematxve  courses  of  action  diat 
nuQT  be  taken  to  satisfy  die  information  requirements  if  the  proposed  syston  finis.  This 
should  be  included  as  tqtpropriate: 

(1)  Back-tq).  A  discussion  shad  be  provided  of  the  back-up  requirements  nec- 
essaiy  to  ensure  die  continued  achievement  of  the  system  functions  given  in  th^  Tune- 
denial  Area  System  Function"  sub-section  above.  "Back-up"  as  used  here  means  die 
redundancy  available  in  die  event  of  die  primaty  system  element  fails. 

(2)  Fallback.  An  explanation  of  Mback  techniques  required  for  ensuring  the 
continued  satisfaction  of  the  specific  reqinrements  of  the  system  shall  be  provided.  Tail¬ 
back"  as  used  hoe  indicates  the  use  of  anodior  system  or  odm-  means  to  acconqpiish  the 
system  requirements.  For  exanqile,  die  fallback  technique  for  an  automated  tyston  nii^t 
be  manual  manqnilation  and  recording  of  data. 

4.  Design  Considerations 

This  section  shall  briefly  describe  how  die  proposed  system  shall  satit^  die  fime- 
tional  requirements  delineated  in  Section  2  and  3.  This  section  diall  restate  the  user's  re¬ 
quirements,  previously  presented  in  nontechnical  terms,  using  any  formalism  needed  for 
die  design  methods  to  be  used  for  development  This  section  nuy  also  be  used  to  docu¬ 
ment  additional  technical  requirements  when  diese  do  not  relate  direedy  to  the  functions 
and  performance  seen  by  the  user  and  have  not  dierefore  been  described  in  Section  3. 
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c  Syttan  DtteripiioH 

This  sub-sectkm  shall  provide  a  goieral  desaiptimi  of  die  proposed  ayston. 
Related  and  mteiiadng  systems  and  dieir  documentation  will  be  refa'oiced  as  required  to 
enhance  this  goieral  deaeration.  Included  widun  thk  descrqition  shall  be  a  chart  showing 
the  relationship  of  die  user  organizations  to  the  major  conqxmenls  of  the  systrai.  This 
chart  diall  be  based  on  die  inf(»mation  included  in  die  "Proposed  Methods  and  Proce¬ 
dures”  sub-section  above. 

b.  System  F$tHedon 

This  sub-section  shaO  describe  die  fimetions  of  the  proposed  system.  This  will 
be  bodi  a  quantitative  and  qualitative  de8cr^<nis  of  how  diese  functions  will  satisfy  die  re¬ 
quirements  of  the  "Specific  Perfomiance  Requiremenls"  sub-section  above.  The  functions 
must  be  described  in  such  a  manner  diat  die  syston  environment  in  Seedm  S  can  be  re¬ 
lated  to  diem. 

e.  Flexibiiity 

This  sob-secdon  dial!  provide  a  descr^tion  of  die  c^[>ability  to  be  incorpOTated 
for  adapting  the  system  to  changing  requirements,  such  as,  andeqiated  opoadorud  changes, 
interaction  with  new  and  proposed  systems  and  planned  periodic  changes.  Conqwnoits 
and  procedures  designed  to  be  subject  to  change  will  be  identified. 
d  System  Data 

Included  in  diis  sub-section  shall  be  a  descrqilion  of  die  inputs,  ouqiuts  and  data 
used  presented  in  Section  3.  It  shall  describe  details  of  data  structures  or  die  encoding  of 
data  diat  arise  fium  technical  requirements  if  die  have  not  previous^  been  addressed 


55 


5.  EDvironment 


This  section  shafl  describe  die  current  AIS  environment  and  attenq^  to  project  the 
environment  needs  to  satisfy  diose  requirements  delineated  in  Sections  2  and  3. 

A  EqmpmaU  Eitvirommatt 

This  section  dull  provide  a  description  of  the  equipmoit  cqubilities  required 
for  die  operation  of  the  proposed  system.  Thb  section  win  present  twoad  descrqMions  of 
die  equqmient  presend^  available  and  die  characteristics  of  any  new  equqmient  necessaiy 
based  on  the  informadon  in  Section  3  above.  A  guideline  for  equipment  to  be  <fescribcd 
foOows: 

•  Processor(8),  including  die  number  of  each  online/ofOine,  and  size  of  internal  storage 

•  Storage  media,  including  die  numb^  of  disk  units,  t^  units,  etc. 

•  Output  devices,  including  die  number  of  each  online/ofOine 

•  hqnit  devices,  including  die  number  of  each  online/ofiQine 

•  Communications  network,  including  line  speed 

b.  Si^port  Software  Environment 

This  sub-section  riull  provide  a  d^ription  of  the  siqiport  software  with  ^ch 
the  computer  programs  to  be  developed  must  interact  hichided  will  be  bodi  support  soft¬ 
ware,  input  and  equipment  simulators  and  test  software,  if  needed.  The  correct  nomoicla- 
ture,  level  (version)  documentation  references  of  each  such  software  system,  subsystem 
and  program  shall  be  provided.  In  addition,  die  language  (compiler,  assemUer,  program, 
query,  etc.),  die  operating  system  and  any  Data  Marugement  System  to  be  ined  must  be 
identified. 
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e.  CommumcaAoms  Requirements 

This  sub-section  shaO  describe  die  support  software  with  which  die  qiphcations 
software  to  be  tteveloped  must  interact  Included  win  be  siqipmt  software,  input  and 
equqmient  simulators  and  test  software,  if  needed.  The  correct  nomenclature,  level  (ver¬ 
sion)  and  documentation  references  of  each  software  system,  subsystem  and  software  unit 
shaO  be  provided.  In  addition,  die  language,  die  operating  system  and  an  Ds':!  Base  Man¬ 
agement  System  to  be  used  wQl  be  identified. 

(1)  Gri^c  Overview.  This  sub-section  shaU  contain  or  refer  to  a  chart  or 
diagram  showing  die  known  communications  requirements  of  the  AIS.  Notations  on  type 
and  peak  volume  of  data  win  be  included  on  die  chart. 

(2)  Hardware.  This  sub-section  shaU  list  die  know  communications  hard¬ 
ware  required  to  siqipoit  die  AIS  being  developed. 

(3)  Software.  This  sub-section  shaU  list  die  known  communications  soft¬ 
ware  required  to  siqiport  die  AIS  being  developed. 

d.  Interfaces 

This  sub-section  shaO  provide  a  descrqition  of  the  interface  requirements.  For 
each  interface,  the  foUowing  should  be  specified: 

•  Description  of  operational  considerations  of  data  transfer,  such  as  security 
considerations 

•  General  description  of  data  transfer  requirements  to  and  firom  die  subject  system  and 
characteristics  of  communicatimis  media/systems  used  for  transfer 

•  Format,  unit  of  measurement,  range  of  values,  data  codes 
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•  Type  of  antkqMted  intei&ce,  such  as  mnual  or  autcxnatic 

•  Aiili(^>ated  intofsce  pfoceduies,  inchidtng  tdeconununkatxms  coBsklaations 

e  Summayoflmpjcts 

This  sub-section  shall  describe  die  antidpated  oiganizatkHial,  nd  developmesi- 
tal  impacts  of  the  proposed  system  on  the  AK  oiiganizations. 

(1 ;  AIS  Organization  htqiacts.  Organizational  inqMcts  may  include  the  modifi- 
cations  of  positional  responsibilities  diat  be  required  by  die  proposed  system.  Anyper- 
sormel  interactions  eliminated  will  be  identified  and  a  discussion  provided  of  the 
possibilities  for  retraining.  AIS  penoimel  responsibilities  will  be  discussed.  Requirements 
for  the  numba*  and  skills  of  additional  personnel  will  be  identified,  hxduded  win  be 
dianges  in  audiorized  strengdi,  location  and  position  identifier,  if  known. 

(2)  AIS  Operadmial  Inqiacts.  This  sub-section  shafl  discuss  impacts  on  die  op¬ 
erational  procedures  of  the  data  processing  centeifs)  to  implement  die  proposed  system. 
Included  will  be  operational  impacts  caused  by  a  change  in  equipment  configurations,  if 
known. 

(3)  AIS  Development  Inqiacts.  This  sub-section  shall  assess  the  personnel  and 
AIS  processing  commitment  necessary  for  die  development  and  testing  of  the  automated 
^stcm.  Addidonal  requirements  for  program  and  data  conversion  will  be  addressed,  if 
known,  along  widi  any  additional  developmental  inqiacts  resulting  fixnn  the  requirements  in 
die  "User  Development  hnpacts"  sub-section  above. 
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/  Failure  ContiugeHcies 

Tflis  sub-section  dull  provide  a  disc  usskm  of  possiUe  fiulures  of  die  hardware 
or  software  ^rstem,  die  consequences  (in  terms  of  system  performance)  of  such  Mures 
and  altemative  courses  of  action  duU  may  be  taken  to  satisfy  the  infovination  requirements. 

(1)  Restart,  hiclude  a  discussion  of  the  restart  crqiabilities  for  ensuring  effective 
and  efBdent  recovery  fiom  a  temporary  problem  within  the  hardware  or  software  systems. 
The  "restart"  ciqiability,  as  used,  is  a  cr^iabifity  to  resume  operation  fixnn  a  point  in  die 
automated  process  prior  to  where  the  proUem  occurred,  widi  appropriate  restmtition  of 
data. 

(2)  Other.  The  fallback  and  back-iqi  contingencies  described  in  the  "Failure 
Contingencies"  sub-section  above  will  be  considered,  as  appropriate. 

g.  Assumpdons  ad  Constraints 

This  sub-section  shall  address  any  data  automation  assumptionc  and  constraints 
dut  relate  to  development  and  operation  of  die  automated  system,  as  qipHcable. 

6.  Security 

To  control  the  dissemination  of  sensitive  information,  all  or  portions  of  this  section 
may  be  maintained  and  distributed  separately  from  the  rmuiinder  of  the  document. 

a.  Biukground  Information 

This  sub-section  shall  provide  background  infomution  on  sensitivity  or  classifi¬ 
cation  of  the  application. 
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b.  Contrtd  PwUs,  VulHerabiMes  and  Safeguards 


This  sub-section  shall  describe  each  control  point,  die  vulnerabilities  at  die  con¬ 
trol  point  and  safeguard  requirements  to  reduce  the  risk  at  the  point  to  an  acceptable  levd. 
This  descr^don  shall  include  consideration  of  alternate  modes  of  operadcm  based  on  emer¬ 
gency,  <&aster  or  accident,  if  appropriate. 

(1)  Control  Points.  This  sub-section  shaD  describe  die  points  in  the  system 
ndiere  there  is  known  vulnerability  ^diich  requires  specific  safeguards.  A  control  point  can 
be  located  at  any  interface  ^ere  there  is  movement  of  data  widi  in  or  between  sites.  The 
following  control  points  should  be  considered: 

•  Input  Control  Points 

■  origin 

■  data  entry 

■  disposition 

■  error  correction 

•  Process  Control  Points 

■  accuracy  and  completeness 

■  system  interfaces 

•  Ouqiut  Control  Points 

■  production 

■  distribution 

(2)  Vulnerabilities.  This  sub-section  shall  describe  the  vulnerabihties  at  each 
control  point  identified  above.  A  vulnerability  is  a  design,  implementation,  or  operational 
condition  inherent  in  the  appUcation  or  system  which  lends  itself  to  error,  loss  or  conipro- 
mise  of  information  or  denial  of  service. 
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(3)  Safeguards.  This  sub-section  shall  describe  die  safi^:uard  requirm^nts  at 
each  control  point  to  reduce  vulnerabilities.  At  least  the  following  areas  should  be 
considered: 


*  administrative  safeguards  -  any  procedure  that  requires  management  stqiervision 

■  personnel 

■  collection  and  p^^eparadon 

■  environment  constraints 

■  distribution 

■  access/permission 

*  physical  safeguards  -  any  physical  means  that  limits  access  to  data,  e.g.,  locked  doors 

■  dedicated  equi^ent 

■  stora^  and  protection 

*  technical  safeguards  -  aiy  automated  process  that  assures  appropriate  processing, 

e.g.,  passwords 

■  process  safeguards 

■  security  identification  requirements 


c.  System  Monitoring  and  Au^B^g 

This  sub-section  shall  describe  all  user  requirements  for  die  production  of  an 
audit  trad  including  automated  reports  or  journals  necessary  to  monitor  die  system.  This 
monitoring  may  be  provided  by  diis  AIS  or  by  other  existing  systems. 

(1)  Journalizing.  This  sub-section  shall  describe  all  journalizing  requirements 
for  the  system.  Journalizing  is  the  recording  of  selected  events  as  they  occur  within  die 
system  and  provides  the  basis  for  monitoring  the  processing  and  use  of  data  and  die  use  of 
computer  resources. 
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(2)  Audit  Trail.  This  sub-section  shaO  describe  aD  user  requiretnoits  for  an 
audit  trail,  such  as  total  transaction  counts  processed  by  location,  time  and  type. 

7.  System  Development  Plan 

This  section  shall  discuss  die  overall  management  approach  to  die  develojmient  and 
implementation  of  the  proposed  c(mq;mter  system,  hicluded  shall  be  a  discussion  of  and 
schedule  for  the  documentation  to  be  produced,  time  frames  for  die  development  of  die 
system  or  die  modules  of  the  system,  necessary  liaison  and  participation  by  odier  organiza¬ 
tions  to  ensure  successful  development  and  any  other  factors  diat  must  be  known  prior  to 
initiating  development.  Reference  may  be  made  to  such  information  contained  in  odier 
documents. 

8.  Cost  Factors 

This  section  shall  provide  a  summary  of  cost  factors  for  die  proposed  system  in  ac¬ 
cordance  with  DOD  Instruction  7041.3,  lalien  ^Ucable.  While  die  proposed  system  re¬ 
sponds  directly  to  die  project  request,  other  factors  may  determine  die  need  for  diis  system, 
such  as  requirements,  telecommunications  considerations  and  the  need  to  interface  with 
other  automated  systems.  General  ahemative  that  may  be  discussed  include  diose  for  sys¬ 
tem  development  and  system  design  widi  consideration  being  given  to  equipment,  software, 
siqiporting  telecommunications  requirements,  oiganizadon,  operation,  etc.  Reference  may 
be  made  to  such  information  contained  in  odier  documents. 

The  above  documentation  standard  [Ref.  8]  was  written  six  (6)  years  ago,  therefore,  it 
does  not  consider  die  new  development  techniques  or  new  technologies.  Yet,  it  is  still  used 
as  die  standard  for  documentit^  AIS  in  DOD. 
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B.  NHCSPP  DRAFT  FUNCTIONAL  DESCRIPTION 


The  Navy  Medicine  EIS  NHCSPP  module  is  to  be  developed  in  a  nq»d  pFOt(^yping 
mode,  ^ch  is  iterative  in  nature.  Therefore,  many  of  the  functional  requiremaits  win  be 
identified  after  a  number  of  iterations.  As  such,  information  for  the  foUowing  areas  is  not 
yet  available  in  its  conq)lete  form. 

•  Database  Characteristics 

•  Inputs 

•  Ou^uts 

•  Security 

•  Costs 

The  foUowing  sub-sections  contain  the  draft  functional  description  for  the  NHCSPP. 

1.  General 

A  Purpose  of  the  Funchontd  Description 

This  Functional  Description  for  the  Navy  Health  Care  Strategic  Planning  Proc¬ 
ess  Module  of  the  Executive  Information  System  provides: 

•  The  System  requirements  which  must  be  satisfied  and  which  wiD  serve  as  a  basis  for 

mutual  understanding  between  the  user  and  the  developer 

•  Information  on  performance  requirements,  preliminary  design  considerations,  and  user 
impacts  including  fixed  and  continuing  costs 

•  A  basis  for  development  of  system  tests 
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b.  Projut  References 

The  documentation  j^Hcable  to  the  histoiy  and  develofmient  of  the  EIS  HeaMi 
Care  Strategic  Planning  Process  Module  is  Hsted  in  die  List  of  References  and  Bibliogrqihy 
of  diis  document. 

c.  Terms  and  AbbrevUrRons 

A  list  of  terms,  abbreviations  and  acronyms  unique  to  this  ;>roject  and  docu¬ 
ment  can  be  found  in  Appendix  B. 

2.  System  Summary 

a.  EIS  Navy  Heattk  Care  StraUgU:  Planning  Process  Module  BatAground 

The  EIS  is  based  on  a  cmtralized  database  system  that  utilizes  the  equabilities 
of  die  mainframe  computer  at  NMIMC  for  database  maintenance.  Also  the  Navy  Medical 
EIS  has  die  same  equability  as  any  commercially  available  EIS  software  to  answer  queries. 
A  corporate  database  is  created  fi-om  data  extracted  monthly  from  extenul  operational  sys¬ 
tems  located  in  medical  treatment  facilities  (MTFsX  dental  treatment  facihties  (DTFs)  and 
outside  organizations.  Oiqiter  V  discusses  die  Navy  Medical  EIS  in  more  detail. 

The  EIS  project  sponsor  is  NMIMC-09E1S.  Once  EIS  is  fully  operational,  it 
will  be  available  at  diir^  seven  (37)  MTF  and  diirty  two  (32)  DTP  sites  to  over  two  hun¬ 
dred  fifty  (250)  users.  These  users  can  be  divided  into  three  (3)  categories:  top-level  ex¬ 
ecutive,  who  win  receive  performance  indicators  and  success  factors,  health  care  analysts 
and  planners,  ^o  require  more  detailed  data  for  problem  anatysis  and  modeling  and  health 
care  facility  managers,  who  use  facility-level  data  to  siqipoit  operations,  management  and 
planning  activities. 
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The  Navy  Health  Care  Strategic  Planning  Process  module,  as  with  odier  £IS 
modules,  win  be  designed  to  provide  infonnation  to  Ae  three  (3)  levels  of  users:  executive 
numagers,  staff  analysts  and  MTF  level  managers.  Executive  managers  require  summaiy 
information  rotted  iq>  from  the  MTFs  throughout  the  cUdmancy.  Staff  analysts  require  ac¬ 
cess  to  facility  level  summary  data  by  unit  identification  code  which  can  be  compared  and 
contrasted  widi  MTFs  of  like  size  and  mission.  Wh'te  MTF  planners  need  information  (hi 
ttieir  MTF  and  its  catchment  area.  A  detatt  discussion  of  the  NHCSPP  is  found  in  Chapter 
IV. 

b.  Objectives 

The  objective  of  the  EIS  Navy  Health  Care  Strategic  Planning  Process  modiile 
is  to  provide  integrated  and  flexible  health  care  planning  infonnation  and  tools  to  users  at 
all  levels.  The  module  must  provide; 


•  Population  based  plaiming 

•  Need  and  Demand  variance  analysis 

•  Gnqihical  and  tabular  display,  comparison  and  analysis  of  multiple  year  (minimum  of 
flvee)  information 

•  Support  oflier  functions  and  information  needs  of  flic  health  care  plaimcrs  in  areas 
such  as: 

■  Budget  formulation /justification 

■  Cost  Benefit  analysis 

■  StafBng  requirements 

■  Problem  identification  and  resolution 
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c.  Ejdaing  Methods  and  Procedures 

Currendy  Ifae  NHCSPP  is  being  used  numuaHy  with  health  care  {danneis  ex¬ 
tracting  data  from  the  source  systems  individual]^  ttien  using  COTS  qneadsheets  and  data¬ 
bases  management  systems  to  anafyze  and  store  the  data. 

d.  Proposed  Methods  and  Procedures 

The  EIS  Navy  Healdi  Care  Strategic  Planning  Process  module  will  consist  of  a 
core  hierarchical  Comshare  Commander  EIS  models  diat  will  reside  on  die  NMIMC  main- 
fiame  host  computer,  augmented  by  user  adaptable  Comshare  One-Up+  models  on  se¬ 
lected  woiicstations.  Maintaining  die  core  system  on  the  central  host  will  provide  data 
integrity  and  control,  facilitate  communication  and  provide  the  aqiacity  required  to  handle 
the  huge  amounts  of  data.  Use  of  Comshare  One-Up+  at  selected  workstations  win  aUow 
the  analysts  to  extend  and  adjqit  die  Health  Care  planner's  ciqiabilities  to  new  and  unique 
requirements.  The  combined  equabilities  of  die  ElS/Comshare  System  wQl  provide  the 
health  care  planner  with  die  information  required  and  a  standard  set  of  tools  udiich  wiD  ob¬ 
viate  die  need  for  unique  triplications  and  diverse  islands  of  automation. 

e.  Assumptions  and  Constraints 

The  following  assumptions  and  constraints  will  apply  to  the  development  of  die 
ms  NHCSPP  Module 

•  data  used  by  the  NHCSPP  module  must  be  accurate 

•  source  data  collection  systems  must  be  responsible  for  the  accuracy  of  the  data 
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3.  Detailed  Characteristics 


The  Mowing  par^rqihs  disciiss  the  detailed  characteristics,  but  in  no  vtsy  hmil 
the  system  to  the  characteratics  listed. 

A  Speqfie  Pafomumee  Requiremaas 

Considefing  diat  tfus  draft  ftmclional  descr^tion  is  being  written  in  the  earliest 
stage  of  the  rqnd  prototyping  process,  determining  the  quantitative  perfonrumce  require¬ 
ments  of  die  NHCSPP  is  beyond  the  scope  of  this  thesis.  Additionalty,  die  iterative  rutture 
of  mpid  prototype  development  win  aUow  for  the  development  of  these  requirements  as  the 
NHCSPP  module  is  developed.  The  Mowing  specific  user  performance  requirements 
must  be  satisfied.  The  NHCSPP  module  must  provide: 

•  die  ability  to  view  the  population  by  catchment  area  or  daimancy  kvel 

•  the  ciqiability  to  accept  and  disphty  data  firom  two  years  prior  as  weH  as  the  current 
year 

•  die  ciqiability  for  side  by  side  conqiatison  of  years,  actual  and  projected,  in  both 
graphical  and  tabular  format 

•  the  capability  to  build  standard  reports  and  to  eiqiort  data  to  local  (C)ne-Up+)  models 

•  a  user-fiiendly,  menu  driven  application  to  input  and/or  move  data  into  models  fi-om 
other  files  and  qipUcadons  and  to  move  data  between  models  )bodi  mainfiame  Sys¬ 
tem  W  models  and  workstation  One-Up+  models) 

•  popubdon  trend  analysis 

•  service  and  care  location  trend  analysis 

•  periodic  iqidates  (monttily  for  most  data)  must  be  incorporaled  into  all  models 

•  indicate  date  oflast  periodic  update  and/or  special  iqidate.  An  iqidate  log  will  be 
maintained  and  accessible  to  users  to  determine  the  currency  of  data. 
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(1)  Accuracy  and  Validity.  Each  &ci]ity  will  be  reqxm^e  for  die  accuracy, 
validity,  and  timefy  i^idate  of  the  data  contained  on  dieir  facility's  NHCSPP  module. 

(2)  Timing.  Timing  of  periodic  iqidates  of  accounting  data  wiD  be  monthty. 
Timing  of  other  periodic  updates  win  be  determined  by  the  nature  of  die  and  wiD  be 
available  duroi^  system  inquiry. 

(3)  Crqpacity  limits.  The  crqiacity  limits  of  Comshare  One-Up+  workstation 
software  five  dimensions  and  approximately  three  hundred  million  cells  require  diat  die 
core  models  reside  on  the  mainfi'ame  System  W  (  nine  viewpoints  and  over  three  hundred 
mOHon  cells). 

b.  FuncAonal  Area  System  Funetums 

The  system  functions  contained  in  die  Comshare,  Commander  EIS,  Executive 
View,  One-Up4-  and  die  System  W  develofmient  tools  are  the  inherent  crqiabilities  as  weU 
as  die  limitations  of  the  system. 

c.  Inputs  and  Ou^uts 

Inputs  win  be  primarily  extracted  firom  population,  patient,  provider,  man¬ 
power,  accounting  and  financial  data.  Ouqiuts  wiU  be  provided  to  die  users  in  accordance 
widi  die  overaU  system  architecture  discussed  in  Section  D,  Design  Considerations. 

d.  Database  Characterisdcs 

Due  to  die  complexity  of  die  NHCSPP,  die  database  characteristics  could  not 
be  established  within  die  scope  of  this  thesis.  Each  step  in  the  NHCSPP  wiD  require  access 
to  different  data.  As  a  result,  the  database  characteristics  need  to  be  developed  in 
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cdlabwalkm  with  die  functional  U8^  It  will  be  critical  w^ioi  dervdopaig  die  data  tfa^  us¬ 
ers  from  aO  levels  of  the  jdanning  process  are  rqiresenled. 
e.  FaSbtre  CatUmgemeuai 

Mainframe  failure  contingencies  w01  be  in  accordance  with  NMIMC  contin¬ 
gency  plans. 

Backiq)  c^iability  in  case  of  communication  fruhire  or  overload  (LAN  or  DDN) 
exists  throi^  die  use  of  dial-iqi  communications  direcdy  with  die  host. 

Woiicstation  failure  will  require  the  operator  to  use  a  different  DSS  configured 
woiicstation  until  die  affected  woilurtation  has  been  repaired.  The  EIS  system  administrator 
win  provide  assistance  in  conjuring  die  workstations  and  in  using  the  system. 

4.  Design  Detail 

The  prott^pe  discussed  in  die  fidlowing  sections  provides  guideliiies  required  for 
die  develoimient  of  functional  capabilities  diat  fulfill  the  requiranaits  given  in  Section  C. 
These  guidelines  in  no  way  limit  or  constrain  die  fiiud  NHCSPP  module  design.  The  "Pro¬ 
totype  Architecture"  section  provides  a  tenqilate  that  could  be  used  in  the  development  of 
the  NHCSPP  module. 

Several  additional  cqiabilities  are  required  by  die  nature  of  diis  planning  tystem  and 
must  be  addressed  in  die  design  phase  of  the  tystem.  These  include: 

*  Security.  Access  to  the  mainframe  model  and  die  corresponding  reports  ("Briefing 
Books")  generated  from  die  model  as  well  as  die  charting  capability  ("Execu-view") 
provided  by  die  Comshare  software  must  be  firmly  limited  to  audiorized  users  of  die 
system.  These  audiorized  users  are  further  broken  into  three  categories: 

Category  1  -  Executive  Level  Managers 

Cat^oty2  -  Staff  Analysts 

Category  3  -  Facility  Plarmers  and  Managers 


69 


*  Data  Feeds  -  Input  Data  wiD  be  provided  to  the  module  from  Ae  fdlowing  sowces: 

Population  Data 

Projected  Heahfa  Care  Needs  Data 

Htooiical  Health  Care  Demand  Data 

IMt  Cost  data 

•  Data  Feeds  -  Outputs.  The  NHCSPP  module  ou^Nits  will  be  recommendations, 
charts  and  printed  tieports  in  siqrport  of  ahemative  delivny  strategy  sdectiofi. 

A  System  Deseri^ioH 

The  EIS  Strategic  Health  Care  Planning  Module  is  being  developed  in  a  rapid 
prototyping  environment.  Prototype  applications  arc  reviewed  by  the  users  for  usability 
and  i^Ucabifity  and  are  incorporated  into  the  system  architecture  and  ^sign  on  an  mere- 
mental  basis.  Therefore  die  overall  (system  description  presented  in  the  fdlowing  para- 
grrqihs  in  no  way  limits  of  constraints  die  final  NHCSPP  module  design.  The  NHCSPP 
module  is  defined  as  a  mainfiame  Comshate  EIS  model  with  the  frdlowing  characteristics: 

(1)  Identify  the  Issues/Problem.  The  HCSPP  module  of  die  EIS  would  not 
siqipott  the  step  of  identifying  an  issue.  This  step  would  be  done  dirou^  die  anafysis  of 
data  within  the  odier  steps  of  die  module.  The  user  would  identify  the  issue  based  on  Di¬ 
agnostic  Related  Group  (DRG)  codes  or  some  other  standard  reporting  method. 

(2)  Specify  the  Population.  The  population  data  frnr  each  area  of  reqionsibilify 
would  be  pulled  once  each  quarter  and  stored  localfy.  The  user  could  do  ad  hoc  reporting, 
trend  analysis  and  population  forecasting. 

(3)  Assess  the  Need.  The  actuarial  models  would  be  stored  on  the  mainfi:ame 
at  die  NMIMC  due  to  die  size  and  complexify  of  diese  models.  The  e^iected  need  for  a 
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particular  catchement  area  could  be  extracted  quarter^.  The  e;q>ected  need  data  would  be 
stored  locally  allowing  die  MTF  planner  to  do  trend  analysis,  ad  hoc  reporting,  forecasting 
etc.  The  actuarial  models  must  contain  die  flexitnlity  to  meet  the  need  of  both  coordinated 
care  sites  and  standard  health  care  delivery  sites. 

(4)  Access  the  Demand.  This  step  in  the  process  would  allow  the  user  to  do  ad 
hoc  repotting  and  trend  analysis  both  on  patient  and  provider  information  as  well  as  cus¬ 
tomer  expectations.  A  mechanism  for  inputting  die  customer  expectations  should  be  avail¬ 
able  to  the  planner.  The  user  could  access  patient  level  information  on  a  particular  episode 
of  care.  Data  from  both  die  Direct  Care  System  and  the  CHAMPUS  would  be  available  to 
the  health  care  planner. 

(5)  Determine  the  Requirements  of  Services.  This  step  requires  die  ability  to 
do  a  variance  analysis  of  expected  need,  historical  demand  and  customer  expectations.  The 
health  care  planner  should  then  be  able  to  choose  on  which  variable  die  requirements  for 
service  will  be  based,  expected  need,  historical  demand  or  customer  e^qiectadon. 

(6)  Forecast  Resource  Requirements.  Here  die  requirements  for  service  are 
converted  to  a  forecast  of  the  resources  required  to  meet  the  health  care  services  needs. 
The  resources  required  will  be  forecasted  without  regard  for  the  ability  to  deliver  the  ciu-e. 

(7)  Begin  Plan  Development.  Contained  in  this  step  is  a  model  of  each  M'l'Fs 
current  stafBng  and  in  place  provider  contracts.  This  stafBng  model  provides  the  planner 
die  ability  to  calculate  die  amount  of  die  total  resources  required.  The  difference  between 
the  total  resources  required  and  the  available  resources  at  die  MTF  is  die  taiget  for  the 
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health  care  planner's  altonative  dehveiy  strategies.  The  atrihty  to  do  "wdut  iT  scoiarios 
with  hospital  stafBng  and  contracts  will  is  of  critical  inqxntance. 

(8)  IDevelop  Alternative  Dehveiy  Strat^es.  In  tfiis  step  the  health  care  {banner 
should  be  able  to  choose  from  an  existing  list  of  ahemative  ddivny  methods  siq)p<Mted  by 
industry  standard  stafBng  and  cost  models.  The  planner  can  choose  what  type  of  contract 
and  at  what  discount  for  a  total  cost  for  die  services  to  be  rendered.  The  planner  should  be 
able  to  select  multiple  ahemadves  and  dien  compare  them  for  cost  effectiveness. 

(9) .  Select  Ahemative.  With  die  ahemadves  laid  out,  the  planner  would 
choose  one  of  die  ahemadves  and  be  able  to  do  "v^iat  iT  scenarios  to  see  the  effect  of  die 
selected  alternative  on  the  difference  between  total  resources  required  and  availaUe  re¬ 
sources.  Once  the  ahemadve  has  been  selected  and  inq^onaited,  die  uso^  should  be  able 
to  add  it  to  die  list  of  available  resources  at  this  particular  MTF. 

The  above  characteristics  only  brie^  describe  the  NHCSPP,  a  detailed  descr^tion 
is  present  in  Cluqiter  IV. 

b.  System  Functions 

The  system  fimctions  contained  in  die  Comshare,  Conunander  EIS,  Executive 
View,  and  Qne-Up+  development  tools  wiD  be  the  inherent  capabilities,  as  well  as  the 
Hmitadons,  of  the  system. 

c.  FtexiMUty 

The  system  functions  and  expansion  capabilities  contained  in  the  Comshare, 
Commander  EIS,  Execu-view,  and  One-up  development  tools  wiD  be  die  determining  fac¬ 
tors  affecting  die  flexibility  of  die  NHCSPP  module. 
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i  System  Data 

The  foUowiiig  paragraphs  briefly  describe  the  inputs,  outputs  and  database 
characteristics  of  die  MiCSPP  module.  Considering  that  diis  draft  functional  descr^tion 
is  being  written  in  die  earliest  stage  of  the  rapid  prototyping  process,  die  types  of  inputs, 
outputs,  and  database  described  here  in  way  hmit  these  areas  for  the  NHCSPP  module. 

(1)  hqiuts.  The  ininits  to  die  NHCSPP  module  shall  include  issues  facing  the 
facilities,  industry  standard  stafEing  models,  population  actuarial  models,  make-buy  models 
and  a  facility  unique  crqiabilities  and  stafibig  models. 

(2)  Outputs.  The  outputs  will  include  graphs  and  reports  to  support  the  selec¬ 
tion  of  an  ahemative  delivery  strategy. 

(3)  Database.  Ehie  to  die  complexity  of  die  NHCSPP,  the  database  character¬ 
istics  could  not  be  established  widiin  the  scope  of  this  diesis.  Each  step  in  die  NHCSPP 
will  require  access  to  dilBferent  data.  As  a  result,  die  database  characteristics  need  to  be  de¬ 
veloped  in  collaboration  with  the  fimctional  users.  It  will  be  critical  when  developing  die 
data  that  users  from  all  levels  of  the  planning  process  be  represented. 

5.  Environment 

The  Automated  Information  Systems  (AIS)  environment  in  i^hich  the  EIS  will  op¬ 
erate  is  comprised  of : 

•  NMIMC  Amdahl  5890-190E  Mainframe  Computer  System 

•  Networked  LANs  at  hospital  and  headquarters  facilities  coimected  via  a  NMIMC 
MED-OA  LAN  to  the  NMIMC  Amdahl  and  data  PBX 

•  AT&T  3B2  LAN  servers 
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*  Personal  computer  workstations 

*  Data  PBX  fOT  dial-in  communications 

The  software  components  of  the  EIS  will  reside  on  the  NMIMC  Mainframe  and  on 
personal  conqruter  workstations.  Data  input  used  by  EIS  will  reside  rai  the  Direct  Access 
Storage  Devices  (DASD)  cormected  to  the  NMIMC  mainframe  on  the  AT&T  3B2  Servers 
and  on  the  persorud  con^ruter  workstations.  Communications  and  interfaces  among  the 
software  and  data  components  will  be  provided  by  the  network  and  by  asynchronous  mo¬ 
dem  dial-in  crqrabDities  using  the  Data  PBX.  The  following  paragrfqjhs  discuss  the  envi- 
rorunent  in  detafl. 

0.  AIS  Equipment  Environment 

The  EIS  will  require  that  software  and  data  components  reside  on  the  NMIMC 
mainframes  (Amdahl),  AT&T  3B2  and  PC  AIS  equipment.  Comshare,  Inc.’s,  System  W 
software,  an  integral  part  of  the  EIS,  wQi  run  on  die  Amdahl  5890-190E  dual  processor 
mainframe  system.  The  mainfiame  is  constandy  being  upgraded  and  ,  at  the  time  of  this 
writing,  consists  of  the  following  equipment  suite; 

*  Ehuil  370  architecture  compatible  processors  divisible  into  four  (4)  multiple  domain 
processors 

•  MVS  and  VM  operating  system 

•  64  megabyte  main  memory,  with  28  megabyte  of  production-oriented  domain 

•  48  -  3380  Amdahl  DASD  spindles  for  a  total  of  7.5  gigabytes 

•  16  -  33 50  Memorex  DASD  spindles  for  a  total  of  3 17  megabytes 

*  5  -  3420  and  8  -  3480  model  tape  units 
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•  96  dial  in  modems 


•  a  total  of  192  hardware  ports. 

PC  equqnnent  running  die  Commander-EIS  t>ased  camptmoit  of  the  EIS  wiD 
reside  on  UNISYS,  Everex  and  possibly  odier  vendors'  Intel  80386-ba8ed  posonal  cmn- 
puter  systems.  These  will  contain  a  minimtim  of  4  megabytes  internal  mcmofy  and  40 
megabytes  of  disk  storage.  EIS  will  require  the  use  of  EGA/VGA  displays.  The  approxi¬ 
mate  number  of  PC  systems  to  be  fielded  is  250. 

Network  servers  (AT&T  362$)  will  in  some  cases  be  used  as  large  data  reposi¬ 
tories  (virtual  disks)  for  PC-based  EIS  software.  All  3B2  servers  now  in  {dace  and  those 
being  delivered  have  16  megabytes  of  main  memory  and  300  megabytes  of  disk  storage, 
150  megabytes  of  which  is  required  by  die  UNIX  OS,  leaving  150  megabytes  fiee  for  net¬ 
work  users. 

b.  Comnutmcadon  Environment 

The  EIS  wQl  use  asynchronous,  9600  and  2400  baud  dial-in  capabilities  and  , 
where  possible,  the  TCP/IP  network  to  coimect  to  the  NMIMC  Mainfirame.  The  coimec- 
thity  is  required  for  access  to  detailed  data  which  can  only  reside  in  large  System  W  model 
files  on  the  mainfi-ame.  The  network,  dirough  Remote  File  Sharing  (RFS)  capabilities  of 
TCP/IP  and  AT&T  UNIX,  also  provides  a  virtual  disk  space  for  personal  conqniters  con¬ 
nected  to  LANs. 

(1)  Network  £>esctjption.  The  overall  communications  environment  wiD  con¬ 
sist  of  TCP/IP  over  Ediemet  LANs  which  are  intemetted  using  MILNET  (DDN).  These 
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netwoii(s  provide  office  automation  capabilities  where  currently  installed.  £IS  will  require 
connectivity  diroi^  Mn.NET  to  all  but  a  few  small,  remote  systems.  The  network  will 
provide  coimection  points  for  AT&T  3B2s,  personal  computers  and  other  ElS-related  sys¬ 
tems.  Connections  to  the  MELNET  (DON)  are  anticquUed  to  be  at  19.2  KBPS.  Actual 
data  transfer  rates  over  this  network  will  be  slower  due  to  the  store  and  forward  nature  of 
an  internet.  Users  widi  loca!  servers  or  users  accessing  local  nuchines  on  their  network 
win  be  operating  at  10  MBPS.  Actual  data  rates  again  wOl  be  slower  depending  iqxm  net¬ 
work  usage.  The  communication  network  will  also  be  the  primary  means  of  software  and 
data  upgrades  for  remote  sites.  Eventually  all  users  with  access  to  the  MED-OA  I.AN  will 
be  able  to  access  die  Corporate  Data  Base  at  NMIMC  Bediesda. 

(2)  Physical  Interface.  Phyacal  interface  will  be  provided  for  each  workstation 
by  either  one  of  tiiree  (3)  versions  of  Ethernet  cards  used  on  MED-OA  LwANs  or  by  dial-iq> 
modems.  The  Ethernet  interface  are  compliant  with  die  IEEE  802.3  Ethernet  standard. 
The  network  will  provide  10  MBPS  local  connectivity  through  either  fiber  optics  or  twisted 
pair  media.  Dial  up  capabilities  will  be  provided  via  2400  or  9600  Baud  modems. 

(3)  Protocol  Interface.  The  network  wiD  use  TCP/IP  protocols.  The  commu¬ 
nications  performed  by  EIS  applications  will  not  directly  interface  with  die  transport  layer 
mechanisms  of  TCP/IP,  and  therefore  no  constraints  on  data  or  record  formats  are  placed 
on  EIS  communications  by  the  network.  Protocol  interface,  where  necessary,  will  be  pro¬ 
vided  by  separate,  stand-alone  software  components.  Dial-up  interface  protocols  will  be 
standard  asynchronous  ASCII  with  capabilities  up  to  MNP  7  error  correction  provided  by 
the  NMIMC  PBX. 
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(4)  i^bcalions  User  Interface.  Comshare,  Inc.'s,  Commander-EIS  wiD  pro¬ 
vide  user  interface  for  all  required  woristations-to-host  and  woikstation'to-server  commu¬ 
nications.  The  ^rphcation  user  interface  will  be  kon,  panel,  and/or  menu  driven.  The  user 
interface  will  ehminate  the  need  for  a  user  knowledgeable  in  communications. 

(5)  Diagnostics.  Sinqrle  user  diagnostic  procedures  will  be  an  important  attrib¬ 
ute  of  the  EIS.  The  user  will  be  informed  by  die  EIS  when  coimections  cannot  be  accom¬ 
plished.  Diagnostic  procedures  win  consist  of  the  fottowing  types  of  procedures; 


•  For  Application  End  Users 

■  Noting  the  error  messs^es  displayed  by  the  system 

■  Performing  sinqile  checks  to  determine  if  the  network  is  active 

•  For  Computer  Operations  and  Field  Assistance  Personnel 

■  Performing  sinqile  diagnostics  on  die  network 

■  Obtaining  siqiport  from  the  local  MED-OA  LAN  administrator 

c.  Support  Sojitivare  Environment 

The  siqiport  software  environment  for  the  mainframe  includes: 

•  IBM  MVS  Operating  System 

•  IBM  VM  Operating  System 

•  IBM  Professional  Office  System  Program  Product  (PROFS) 

•  AD  ABAS/NATURAL  DBMS/Queiy  Language 

•  IBM  MVS  Time  Sharing  Option  (TSO)  widi  Interactive  Software  Produedvity  Facility 
(ISPF) 
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•  Comshare,  Inc.,  System  W  Data  Modeling  Facility 

•  Top  Secret  Mainframe  Security  Package 

System  W,  ADABAS/NATURAL,  and  TSO/ISPF  aD  run  under  ttie  MVS 
erating  system.  System  W  is  used  to  develop  data  models  for  view  by  PC-tMsed 
Commander-EIS  systems.  ADABAS/NATURAL  queries  are  made  on  the  NMIMC  Cor¬ 
porate  Database  to  produce  flat  files  for  importing  into  System  W.  MVS/TSO  is  file  de¬ 
velopment  operating  system  and  die  utilities  set  used  to  develop  mainframe  models.  The 
software  support  environment  for  die  PC  workstation  consists  of  : 

•  hfrerosoft  MS-DOS  3.3  or  higher 

•  Comshare,  Inc.,  Commander-EIS 

•  Comshare,  Inc.,  One-Up+ 

Comshare,  hic.'s  Commander-EIS  is  an  EIS  development  sheD  which  will  run 
under  MS-DOS  as  an  applications  development  and  run  time  EIS  tool.  Comshare,  hic.'s 
One-Up+  is  a  PC-based  modeling  tool  which  mirrors  the  capabilities  of  System  W  on  die 
mainfiame.  This  tool  will  be  used  to  develop  small  PC  or  LAN  based  Models. 
d.  Software  Interfaces 

EIS  interface  widi  other  software  components/operational  systems  will  be  via 
inqxnt  of  flat  files  produced  by  ADABAS/NATURAL  queries  of  those  systems.  The  de¬ 
tails  of  this  interface  are  provided  in  Section  D,  Design  Considerations.  EIS  software 
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conqxmenls  cm  die  mainframe  (System  W)  and  PC  (Commander-EIS)  wiD  intoface  to 
provide  the  user  views  of  detailed  data  residing  on  the  mainframe.  This  interface  is  already 
integrated  into  Comshare  off-the-shelf  software. 

6.  Security 

No  classified  data  will  be  processed  by  the  EIS.  Sensitive  data  will  consist  of  pri¬ 
marily  financial  data  on  Navy  Medical  programs  and  facilities  as  well  as  privacy  act  infor¬ 
mation  fixrni  direct  care  and  CHAMPUS  patient  and  provider  data.  Access  to  this  data  will 
be  controlled  by  System  W  and  Commander-EIS  software  components  using  encrypted 
user  identification  passed  between  System  W  and  Commander-EIS  software  ctmiponents. 
This  user  identification  data  is  managed  by  the  local  EIS  adnunistrators  as  delegated  by  the 
EIS  information  provider.  The  EIS  information  provider  will  control  nliidi  users  have  ac¬ 
cess  to  wdiich  models  using  information  security  features  in  System  W.  System  W  models 
on  die  mainframe  and  3B2  servers  will  be  read-only  and  constitute  die  "models  of  record" 
from  a  data  integrity  standpoint. 

7.  System  Development  Plan 

Determining  the  System  Development  Plan  for  the  NHCSPP  module  of  die  Navy 
Medical  EIS  is  beyond  the  scope  of  this  thesis.  This  wQI  be  done  by  NMIMC. 

8.  Costs 

Determining  the  cost  to  develop  die  NHCSPP  module  of  the  Navy  Medicine  EIS  is 
beyond  the  scope  of  this  diesis.  This  win  be  done  by  NMIMC. 

The  next  chapter  will  discuss  die  recommendations  and  conclusions  drawn  from  the 
research. 
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VII.  CONCLUSIONS  AND  RECOMMENDATIONS 


This  provides  recommoidalknis  and  conclusions  drawn  from  die  research  ccn- 
ducted. 

A.  PROBLEMS  WITH  THE  PROCESS 

The  fdlowing  paragraphs  discuss  problems  identified  during  this  research. 

1.  Data  Comparison 

The  primary  problem  identified  with  the  current  NHCSPP  becomes  readily  appar¬ 
ent  ^en  comparing  Direct  Care  system  data  and  the  CHAMPUS  data.  The  CHAMPUS 
systems  use  Diagnostic  Related  Group  (DRG),  IntemaliQnal  Classification  of  Disease  ver¬ 
sion  nine  (IDC9)  and  Clinical  Procedure  Terminology  version  four  (CPT4)  codes.  While, 
on  die  other  hand,  die  Direct  Care  System  costs  (material,  maiqxiwer,  facility  overhear, 
etc.)  using  wodk  center  costing  and  performance  reporting.  Therefore,  vdien  the  two  areas 
are  compared,  die  direct  care  data  must  be  man^ulated  in  order  to  devolop  an  estimate  of 
the  per  patient  cost  which  dien  can  be  compared  to  the  CHAMPUS  per  patient  cost  This 
man^ulation  and  massaging  of  die  data  introduces  errors,  making  die  resultant  data  ques¬ 
tionable.  This  in  turn  makes  make  or  buy  deciaons  questionable. 

2.  Standardization  of  the  HC8PP 

During  an  interview  with  die  Tri-Service  Project  Office  [Ref.  10],  r^arding  the 
NHCSPP,  cmicem  was  expressed  over  tt^  fact  that  each  service  is  develof^  a  sovice 
unique  HCSPP.  Ctqitain  (CAPT)  Hood,  USN  and  his  directors,  expressed  the  concern 
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ttut  all  services  are  planning  health  care  deliveiy  systems  with  a  different  process.  This 
separate  development  hinders  CCP  efifoits  and  makes  more  difficult  die  Tri-service  efforts 
to  get  die  most  out  of  shrinking  resources.  [Ref.  10] 

3.  Unit  Costing 

The  movement  is  under  way,  within  DOD,  to  orogress  from  die  present  method  of 
budgeting  for  health  care  to  a  capitation  method  [Ref  10].  Capitation  budgeting  is  budget¬ 
ing  on  a  per  beneficiaiy  basis.  The  problem,  however,  is  diat  the  Navy  Medical  Depart¬ 
ment  can  not  isolate  die  cost  of  each  procedure  performed,  therefore  estimating  die 
monthly  or  yeariy  cost  of  each  beneficiaiy  is  almost  impossiUe.  Without  diis  estimate,  it  is 
difScult  to  know  what  resource  requirements  win  be. 

B.  PROBLEMS  WITH  THE  NAVY  MEDICAL  EIS 
1.  ElSorDSS 

What  the  users  of  the  Navy  Medical  EIS  need  is  a  system  that  provides  both  sum- 
maty  and  detailed  information  that  may  be  combined  with  analytical  tools.  As  such,  users 
need  a  system  that  assists  their  decision  making  ctqiabilities  in  resource  aUocation.  The 
question  then  becomes  which  is  needed,  an  Executive  Information  System  (EIS)  or  a  Deci¬ 
sion  Support  System  (DSS)?  Below  are  the  definitions  of  each  system: 

EIS  -  a  computer-based  system  that  serves  the  information  needs  of  top  executives.  It 
provides  rapid  access  to  timely  information  and  direct  access  to  management  re¬ 
ports.  It  is  very  user-fiiendty,  supported  by  graphics,  and  provides  exceptions' 
reporting  and  "drin-down”  ciqiabilities.  Is  also  easily  connected  widi  on-line  in¬ 
formation  services  and  electronic  nudl.  [Ref  1 1  ] 
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DSS  -  an  interactive,  flexible,  and  adaptable  computer-based  infonnatim  system  that 
utilizes  decision  rules,  models,  and  model  base  coupled  with  comprehensive  da¬ 
tabase  and  the  decision  maker's  own  insight,  leading  to  specific,  in:4)lementable 
decisions  in  solving  problems  that  would  not  be  amenable  to  man^ement  sci¬ 
ence  optimization  models  per  se.  A  DSS  supports  complex  decision  makii^ 
and  increases  effectiveness.  [Ref.  11] 

After  interviewing  many  of  die  potential  users,  the  follow  description  for  a  Executive  Sup¬ 
port  System  (ESS)  describes  the  users  needs. 

ESS  -  The  ESS  is  a  conqnehensive  support  system  that  goes  beyond  EIS  to  include 
communication,  office  automation,  analysis  siqiport  and  intelligence.  [Ref.  1 1] 

C.  RESPONSE  FROM  THE  WORKING  HEALTH  CARE  PLANNERS 

The  NHCSPP  is  currently  being  employed  at  staff  commands  and  at  the  MTFs  in  man¬ 
ual  mode.  Several  interviews  where  conducted  with  prospective  end-users  of  the  NHCSPP 
module  of  the  Navy  Medical  EIS.  Following  are  concerns  expressed  by  personnelinter- 
viewed  in  regard  to  the  NHCSPP  itself  and  any  future  NHCSPP  module. 

1.  Executive  Managers 

The  executive  managers  fi’om  BUMED  [Ref.  12  A  13]  and  the  Tricare  Project  Of¬ 
fice  [Ref  10],  offered  die  following  recommendations  regarding  the  automation  of  die 
NHCSPP: 

•  data  be  tri-service.  This  includes  population,  historical  workload,  financial,  staffing  and 
patient  (direct  care  and  CHAMPUS)  data. 


82 


•  the  same  planning  tool  be  used  throu^out  the  entire  planning  and  budgeting  chain  of 
ctmimand  starting  at  the  DOD  level  and  flowing  downward  du-ough  dte  diree  (3) 
services 

•  as  much  interaction  as  possible 

•  a  crosswalk  be  established  between  die  direct  care  patient  data  and  die  CHAMPUS 
data 

•  the  software  has  "what  if*  capabilities 

•  the  services  begin  to  do  patient  level  accounting 

•  militaiy  staffing  of  die  MTFs  be  done  across  the  services,  shifting  assets  between  serv¬ 
ices  as  the  population  demands 

•  the  software  allow  for  future  year  projection  in  all  steps 
2.  Staff  Analysts 

The  staff  analysts  at  BUMED  [Ref  14  &  IS]  proposed  die  foUowing 
recommendations  r^arding  the  automation  of  the  NHCSPP: 

•  the  system  be  flexible  enough  to  allow  them  to  continue  to  do  a  detailed  level  of  pro¬ 
gram  costing 

•  the  system  be  responsive  to  the  move  to  capitation  budgeting 

•  the  system  must  be  able  to  do  planning  and  budgeting  by  Unit  Identification  Code 
(UIC) 

•  the  source  data  be  provided  in  a  timely  manner  to  the  analysts 

•  there  be  standardization  of  data  across  die  services 

•  diere  be  on-line  access  to  the  source  data 

•  there  be  ad  hoc  capabilities  with  each  step  of  the  NHCSPP 

•  the  software  allow  for  future  year  projection  in  all  steps 
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3.  Facility  Planner/Manager 

The  facility  planner  at  Naval  Hospital  Portsmouth,  Viiiginia,  lieutenant  Com¬ 
mander  (LXZIDR)  John  Tenqiesco,  Medical  Service  Corps,  United  States  Navy  [Ref.  6], 
considered  by  many  in  DOD  to  be  an  e;q>ert  in  health  care  planning,  offered  the  fdiowing 
recommendations: 

•  die  same  planning  tool  be  used  dirou^out  the  entire  plannii\g  and  budgeting  chain  of 
command  starting  at  the  DOD  level  and  flowing  downward  throi^  die  three  (3) 
services 

•  as  much  interaction  as  possible 

•  the  system  provide  decision  and  analytical  support 

•  a  crosswalk  be  established  between  the  direct  care  patient  data  and  the  CHAMPUS 
data 

•  the  software  contain  die  ability  to  have  "vihat  iT  capabilities  in  regard  to  each  step  in 
the  NHCSPP 

•  the  services  b^in  to  do  patient  level  accounting 

•  militaiy  stafBng  of  die  MTFs  be  done  across  die  services,  shifting  assets  between  serv¬ 
ices  as  the  population  demands 

•  die  software  allow  for  future  year  projection  in  all  steps 


D.  RECOMMENDATIONS 

The  foOowing  recommendations  are  made  regarding  the  development  and  deployment 
of  the  Navy  Medical  EIS  NHCSPP  module. 

1.  Standardization  of  the  Health  Care  Planning  Process 

The  current  healdi  care  planning  process  difiers  within  each  service  and  at  die 
DOD  level  [Ref.  10].  In  order  to  effectively  manage  the  military  healdi  care  system  in  this 
time  of  budget  cuts  and  force  right-sizing,  all  services  need  to  do  health  care  planning  in 
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the  same  manner.  At  the  EXDD  level,  a  health  care  strategic  planning  process  should  be  <k- 
vel(^d  and  used  by  the  service  conqxments.  This  would  enaUe  bucketing  to  be  based  (m 
common  planning  processes  for  aO  DOD  components. 

2.  The  Navy  Medical  EIS  NHCSPP  module 

Upon  conq)Ietion  of  the  research,  it  is  evident  that  further  r^arch  in  required. 
This  additional  research  is  beyond  the  scope  of  this  thesis.  Yet,  if  the  NHCSPP  module  of 
die  Navy  Medical  EIS  is  to  be  completely  and  successfully  im|demented,  die  MTF  level 
health  care  planners,  staff  analysts  and  executive  mam^es  need  to  collaborate  on  die  devel¬ 
opment  of  a  detailed  functional  description.  This  document  contains  a  rou^  draft  of  die 
functional  description  and  should  act  as  a  springboard  for  further  discussion. 

3.  Department  of  Defense  Automation  Information  Systems  Documentation 

Standard 

The  research  indicates  that  Navy  Health  Care  Strategic  Planning  is  an  extremely 
complex  and  intricate  process  and  as  such,  traditional  mediodologies  diat  emphasize  cap¬ 
turing  and  representing  users'  requirements  upfront,  i.e.  DOD-STD-793SA,  are  not  appro¬ 
priate  for  automating  the  planning  process.  The  development  of  strategic  planning  tools  is 
an  extremely  complex  process  that  requires  the  use  of  new  development  methologies,  i.e., 
rapid  prototyping,  incremental  development,  etc..  In  many  cases,  for  example  the 
NHCSPP,  an  of  the  users'  requirements  can  not  be  identified  until  the  tool  has  been  tested 
in  a  operational  environment.  Therefore,  expecting  to  capture  ad  user  requirements  up- 
fixmt  is  not  feasible  yet,  this  is  a  requirement  of  the  current  standards. 
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The  Depaitment  of  Defense  Automation  InfcvmaliQn  Systems  Docun^ntation 
Standard,  DOD-STD-7935A,  October  1988  [Ref.  8]  was  written  six  years  i^o  and  as 
such,  does  not  consider  new  AIS  developmental  techniques  or  new  technologies.  Yet,  diis 
standard  is  stiU  used  for  documenting  AIS  in  EKDD.  This  standard  should  be  \q>date  to  re¬ 
flect  chaises  in  technology. 

4.  Executive  Si’  ppoit  System 

Upon  completing  the  research,  it  is  clear  that  what  the  users  at  all  level  require  is  an 
Executive  Support  System  (ESS).  The  ESS  incorporates  the  decision  support  require¬ 
ments  of  the  headquarters  and  facility  level  plarmer  with  the  executive  information  require¬ 
ments  of  the  executive  managers.  This  would  allow  the  development  and  use  of  one 
system  across  the  echelons  of  comnuind  and  decision  making. 


86 


APPENDK  TERMS  AND  ABBREVIATIONS 


AG 

Activity  Groiq) 

AIS 

Automated  Iiif(»mation  System 

BUMED 

Bureau  of  Medicine  and  Surgery 

DASD 

Direct  Access  Storage  £)evice 

DBMS 

Data  Base  Management  Systems 

DDN 

Defense  Data  Network 

DTF 

Dental  Treatment  Facility 

DSS 

Decision  Support  System 

EE 

Expense  Element 

EIS 

Executive  Information  System 

EOB 

Expense  Operation  Budget 

HSO 

Health  Care  Support  Organization 

ISPF 

interactive  Software  Productivity  Facility 

JCL 

Job  Control  Language 

LAN 

Local  Area  Network 

MBPS 

Mega  Bits  Per  Second 

MED-OA 

Medical  Office  Automation  Department 

MEPRS 

Medical  Ejqrense  and  Performance  Reporting  System 

MILNET 

Militaty  Network 

MTF 

Medical  Treatment  FacOity 

MVS 

Multiple  Virtual  System 

NH 

Naval  Hospital 

NMIMC 

Naval  Medical  Information  Managemoit  Center 

OPTAR 

Operation  Target 

PBX 

PubHc  Branch  Exchange 

PCDM 

Personal  Computer  Data  Management  File 

PM 

Performance  Measure 

PROFS 

Professional  Office  System  Program  Product 

RFS 

Remote  File  Sharing 

SAG 

Sub- Activity  Group 

TCP/IP 

Transmission  Control  Protocol/Intemet  Protocol 

TSO 

Time  Sharing  Option 

UIC 

Unit  Identification  Code 

VM 

Virtual  Machine 

WIRS 

Worldwide  Inpatient  Reporting  System 

WORS 

Worldwide  Outpatient  Reporting  System 
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